Trouble copying an ATTiny45 to another ATTiny45

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a pre-programmed ATTiny45 and six unprogrammed ATTiny45's. I want to program the six unprogrammed IC's to be identical to the one programmed ATTiny45 that I have. However, I can't get the ATTiny45 into ISP mode.

I've got an STK500v2 and by wiring it up for HVSP mode I seem to be able to read off the Flash and EEPROM and save them to Hex files.

The fuse bits show up as being Ext - 0xFF High - 0xFF Low - 0xFF. That's all fine, but if I try to change any of the fuse bits on the already programmed tiny, AVR Studio (4.17) just reports back an error trying to program the fuse bits.

I took one of my new tiny's, set the fuse bits to 0xFF 0xFF 0xFF (it still lets me re-program them to something else, unlike the original). I also downloaded the flash and eeprom onto the new chip, but the new chip does not work when plugged into the same socket as the original chip (and yes, the original chip is working).

Any help? I'd be happy to provide more information

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a guess – is your original chip locked? Did you check your hex file? Mayby it contain only FFs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I want to program the six unprogrammed IC's to be identical to the one programmed ATTiny45 that I have.
So what stopping you from programming he chip from your original code? You DO have the original code don't you??
Quote:
I can't get the ATTiny45 into ISP mode.
Which ATTiny45? The original or the new ones??

Are you trying to COPY the original chip?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did check the flash hex file I downloaded and it's not all FF's--that was my first guess too.

js - No, I don't have the original code, that's why I need to copy the chip. The code is under the GPL, so yes, it's okay that I copy it off the chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I downloaded and it's not all FF's--that was my first guess too.


Post a few lines--is it 01-02-03-...?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

and it's not all FF's--

But could still be locked. The actual byte patter you read from a locked AVR is the byte value of the address so 00 00 01 01 02 02 03 03 etc.

For AVRs up to 8K a .hex file based at 0x00 will almost inevitably start:

:nn000000??C?

As that 0xC? is part of the RJMP opcode.

For AVRs above 8K the .hex will probably start:

:nn0000000?94

or

:nn0000000?95

as the 0x94 0x95 is the upper part of a JMP opcode.

Cliff

PS it is utter drivel to suggest that because code is GPL you have a right to take a binary copy. The GPL states that the source code should always be made available - how are you going to uphold that requirement?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

PS it is utter drivel to suggest that because code is GPL you have a right to take a binary copy. The GPL states that the source code should always be made available - how are you going to uphold that requirement?

Not to mention that if it is under GPL, and you have the source code, there is nothing stopping you from re-creating the binary image. So again, no good reason to try and "copy" one chip to another.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maybe you're right, the .hex file looks like:

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
...

Thanks for the ethical discussion, I'd really just like some information since it's a little difficult to find. Does this type of hex file mean it is locked? How do you lock code once it's on the chip? Can it ever be unlocked?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

maybe you're right, the .hex file looks like:
Code:

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0

Quote:

I downloaded and it's not all FF's--that was my first guess too.


??? Well, I guess if you aren't familiar at all with Intel HEX it isn't all ff's--but did you really think a real program would have >>that many<< ff's?!?

Either your chip is locked (most likely), or you have a bogus ISP setup. If you can read the chip signature and do other operations then that part is probably OK. So its a locked chip.

So get a fresh .HEX from the "distributor", or get the source and rebuild.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fowdawgg wrote:
Can it ever be unlocked?

Yes, it can be unlocked by a full erase.
Then the lock bits and the previous content was erased.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Does this type of hex file mean it is locked?

Nope that looks more like one that is empty but maybe some of the devices just return 0xFF for every location which would look the same as that.

So if the device is locked and you don't have the source all you need do is email the GPL licensor and ask them to make a copy of the GPLd code available to you. In theory GPL swings both ways - they can't really set the lock bits because the user should always be able to re-create the code AND load it into the device. While you can still do this after you've built the source because an erase clears the lock bits it therefore makes their setting of the lockbits a bit pointless (we were once caught by this after I implemented an "SHA256 signed bootloader" in a device. The FSF and supporters said we still had to make it possible for the customer to rebuilt AND load their own image into the device which meant that I had to make my signing program available - it kind of defeated the whole point of the security - but that's GPL for you.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess I should mention that this is the stuff I read out using HVSP. ISP couldn't read the device at all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

ISP couldn't read the device at all.

Again, what does that mean? With modern AVRs you can still read the signature even if locked. If you cannot, then your ISP setup is not correct.

There is another possibility, upon reflection--if the original producer unprogrammed the SPIEN fuse, perhaps just to prevent readout, then indeed you would not be able to read the signature via ISP.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a part that small, it's entirely possible that the original programmer programmed the RSTDISBL fuse. It may not have been done with manevolent intent because it may be necessary to access the additional I/O pin for full functionality. It would have the effect of making it impossible to use normal ISP to reprogram the chip, but it should still always be possible to use HVSP to access the chip.

I'd like to echo Lee's point: Try verifying the signature bytes. If your programming interface is working correctly, then you should at least be able to read them reliably. If you cannot read them correctly, even using HVSP, then there's something wrong with your HVSP set-up, and you'll have to fix it before you can even begin to trust anything else you read from the device.

(Off-topic: What if your project uses GPL code, and you intend to abide by the GPL by providing the full source and instructions for compiling the code to all recipients, but you're constrained to using older/cheaper hardware that's only available with a OTP PROM? Can you abide with the GPL's requirements regarding the ability to load the code by including instructions for desoldering the chip and acquiring a replacement part?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the original programmer programmed the RSTDISBL fuse.

Aaah, forgot about that one. You are correct, of course. A quick visual inspection of the board (or even easier the schematic) should indicate whether that pin is used as I/O.

(It gets more and more curious--OP mentioned the GPL. Thus, it is probably a project on the Web somewhere, and typically those have schematics and the like posted. If not, how does he know about the GPL?)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its also possible, that the original ATtiny contain a bootloader to reprogram after the RSTDISBL fuse was set.

Typically such a bootloader contain no read back function to be as small as possible.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds complicated with the bootloader. I believe the RSTDISBL fuse is set, because reading the chip with ISP doesn't give me the signature (that's what I mean by ISP not working), however when I hook up HVSP I do get the signature read back correctly--the problem is that I can't un-set any of those fuses. When I try, I get a programming error (using AVR Studio v4). Would changing the fuses so I can use ISP perhaps make it so I can read the flash? (The snippet I included earlier is what gets read when I use HVSP to read it)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
(we were once caught by this after I implemented an "SHA256 signed bootloader" in a device. The FSF and supporters said we still had to make it possible for the customer to rebuilt AND load their own image into the device which meant that I had to make my signing program available - it kind of defeated the whole point of the security - but that's GPL for you.

If the Bootloader and signing program were not based on GPL'd code you do not need to release the code for it. Even if the main application is GPL'd. (provided there is no linkage between the two)

Even if the signing program was GPL'd, you do not have to release the signing keys. They can remain private. (GPL covers the code, not the data, and signing keys are considered data)

As for letting them build & load their own code, they can always build, and load via ISP and the erase command. There is no rule that says they must be able to do it via the bootloader the same as you officially do.

This is an important distinction, as it provides you a mechanism for warranty control. A hacked (embedded) device is no longer covered under warranty. Thus if they erase the chip, and install their own bootloader or application, then they have voided the warranty.

[disclosure: I am not a lawyer, and the above should not be taken as sound legal advice or fact, it is only my personal opinion/understanding]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
clawson wrote:
(we were once caught by this after I implemented an "SHA256 signed bootloader" in a device. The FSF and supporters said we still had to make it possible for the customer to rebuilt AND load their own image into the device which meant that I had to make my signing program available - it kind of defeated the whole point of the security - but that's GPL for you.

If the Bootloader and signing program were not based on GPL'd code you do not need to release the code for it. Even if the main application is GPL'd. (provided there is no linkage between the two)

Even if the signing program was GPL'd, you do not have to release the signing keys. They can remain private. (GPL covers the code, not the data, and signing keys are considered data)

As for letting them build & load their own code, they can always build, and load via ISP and the erase command. There is no rule that says they must be able to do it via the bootloader the same as you officially do.

This is an important distinction, as it provides you a mechanism for warranty control. A hacked (embedded) device is no longer covered under warranty. Thus if they erase the chip, and install their own bootloader or application, then they have voided the warranty.

[disclosure: I am not a lawyer, and the above should not be taken as sound legal advice or fact, it is only my personal opinion/understanding]

I got curious about this so I looked it up. GPLv2 doesn't appear to have very much to say at all about this, so it's probably safe to say if you are bound by GPLv2, you probably don't have any obligations to provide instructions on how to load the software once it's been compiled - it's up to the modifier to figure it out.

GPLv3, on the other hand, says that, if you distribute your object code as part of a "User Product" (where "User Product" is any class of consumer electronic device which is likely have personal, family, or household uses, or any electronic device designed to be incorporated into a dwelling), then you must provide complete "installation information" (where "installation information" is defined as methods, procedures, authorization keys, or other information required to install and execute modified versions of the software).

It also says that a GPLv3 program cannot be deemed to be part of an effective technological measure as defined by article 11 of the 1996 WIPO copyright treaty or similar national laws (implied here is the DMCA), and that, in choosing to incorporate a GPLv3-covered work in the consumer product you convey, the you waive the right to enforce any prohibition against circumvention of such technological measures, for the purposes of replacing the GPLv3 covered work with a modified version.

I suppose this could be interpreted as meaning that an explanation of how to perform a complete chip erase followed by ISP programming would be an adequate procedure for installing the replacement firmware without imposing any obligation to disclose anything about the bootloader.

To answer my previous question, this requirement doesn't apply if neither you nor any third party would normally have any method of loading modified code on the product, with a specific example of situations where the code is stored permanently in ROM.

By the way, I am not a lawyer either. This is not legal advice, it is just my personal interpretation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch / Luke,

You are right. I think the suggestion was, however, that we would have to sign images for anyone who sent one that they intended to load onto the device. Given the normal development cycle and the likelihood that their modification of the code would likely be an iterative process (we weren't going out of our way to explain the electronics to them either so a lot of it would be by reverse engineering and inspection) the signing thing could quickly turn into a can of worms.

Luckily for me we stopped manufacture of the product before this became a big issue. The only real sanction in the FSF's legal artillery is a "cease and desist" order. If you've already ceased there's not a lot more they can do.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I think the suggestion was, however, that we would have to sign images for anyone who sent one that they intended to load onto the device.

[putting GPLv3 aside for the moment... v3 definitely has some clauses in it that are going to turn businesses away, as Luke outlined above]

I don't see signing as a requirement either. As there is no clause that says that they must be able to load the device through the same mechanism as you do. It is perfectly valid to require that the hacker have to solder a JTAG interface onto the board in order to load their own code, or even remove the chip for programming. Either way, it appears to be a moot point now, as you no longer make the product, I was just surprised at the direction you guys took there.

In the end you have to follow the advice your lawyer gives... hopefully you have a lawyer that is well versed in GPL.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So can anyone explain why I cannot un-program the RSTDISBL or the SPIEN fuses on a chip in HVSP?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you are in HVSP, can you reliably and repeatedly read the correct chip signature?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, 100% of the time I read back the correct 0x1E 0x92 0x06

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I understand now. The lockbits have been programmed, so even though it says I can read the device, since it's locked I end up with an empty .hex file (all 'FF's). And I can't remove the lockbits without erasing the device, I also can't program the fuse bits without erasing the device, correct?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

correct

Writing code is like having sex.... make one little mistake, and you're supporting it for life.