Writing the signature bytes.

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

Hi, 
I vaguely remember that someone figured out how to write the signature bytes. 
I have a batch of atmel chips where atmel (Can't get used to saying microchip) forgot to do so (correctly) in the factory. They are replacing the chips, so the bad chips are now available for "experiments" :-) 

 

I have searched the forum, and the proof that this is possible is evident on the forum beginning in about 2005. People are reporting accidentally wiping their signature bytes.  

 

The hardware DFU bootloader is also missing. Does anybody have a binary for that?

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

Why is it important to correct them? Usually the only use for them is during programming to verify you are talking to the right kind of device. Even if that gives the "wrong answer" there's usually an over-ride to say "ignore signature check".

 

DFU is in AVR1916. The .ZIP file that comes with AVR1916 has the complete source trees to build all variants of DFU but I think it also contains the prebuild .HEX for most devices too.

Last Edited: Mon. Jul 30, 2018 - 08:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes. I use avrdude, so -F is the option to override the check for the correct signature. 

 

It is not really important  to write it correctly. With the chips apparently having skipped part of the factory test-and-initialize procedure I can't be sure that these chips are 100% fine. I can't sell them. Worst case, there is say a stuck-at-zero bit in the flash which happens to be set to zero with my current version of the firmware, and then when I email an updated version of the firmware to a client the bit needs to be "1" and things fail. That sort of games is not what you play with paying customers. So these chips are for experiments and home use for myself. So one of the experiments would be to try to write to the non-writable part of the chip. :-) 

 

With the DFU firmware missing, I can't field-upgrade them as I'm used to. I have a resistor on the HWB pin so that hitting reset "in the field" brings the chip into DFU mode, while a normal poweron will run my firmware. Actually that's also the normal way that I program them. When the DFU upload works, I know for sure that the part around the USB works.... :-) 

 

Thanks for the pointer. I'll check it out.  That AVR1916 is for Xmega devices. I have an at90usb162 here. 
I found: https://www.avrfreaks.net/forum/...

which links to the atmel.com site... which is down (Permanently??). I can understand rebranding of the datasheets and stuff like that. But killing hundreds if not thousands of external links for people using your processors is not nice.  

I found another topic with apparently another link but that links to.... the microchip home page. https://www.avrfreaks.net/forum/... Sigh. 

 

Update: Found it! http://ww1.microchip.com/downloa...

 

 

Last Edited: Mon. Jul 30, 2018 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are a distributor can't you just return them to your supplier on the basis of "not fit for purpose". the fault here is Microchip's so they should be the ones to bear the cost and sort it out.

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

99% of the "my chip doesn't work" complaints always end up as "user error". So I start out with assuming that I've done something wrong. 

 

In this case, I asked microchip support and they came back with: "You're not the first to report bad signature bytes on these chips with a few production dates. What production dates do your chips have?". 

 

After I had double checked that I could reproduce the problem I followed the directions towards getting my chips replaced. That is being worked on (I'm assuming they are on their way), and so I now have a few chips that are paid-for by Microchip's mistake. Those are available for experiments. 

My turnover is not such that I buy hundreds of chips in one go. This project with the AT90USB162 was started for personal purposes and then put in the shop. We are setup to do small batches so I don't mind every now and then building a batch of 5 or ten of these boards. 

 

Anyway, with MY small volume, microchip did not opt to verify my claim that the chips were defective, and simply replaced them. I'm guessing that "what date code do you have then?" prevents cheaters who want to get free chips. 

Last Edited: Mon. Jul 30, 2018 - 02:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've just fallen foul to this issue a few days ago (see my thread https://www.avrfreaks.net/forum/...) and am having difficulty getting access to microchip support.

 

Like you my turn over is low, but this has cost me two days (that I really can't afford) at the most busy time I've ever had and my client is getting very impatient. Speaking as an ex-IC test engineer, this is really most likely a human error at their test facility, and I guess some trays ended up in the supply chain that should not have gone to scrap :( I've seen how hard the floor staff work first hand, and I can easily see how it could happen in many ways.

 

With their attitude of 'you're too small to warrant at least some basic verification' I am likely to move all prototype work over to STMxx products and ditch the PIC and ATxx lines I use at the moment as my trust in them is waning.

 

Dave.