Last fall we ordered several thousand AVR ATTiny2313s, which we wanted to have Digi-Key program.
We went through the process we were given, which was a form where we could attach a single file, the Flash section of the chip. Fine.
There is no place, that I’ve seen, in the Digi-Key process to attach a second file, which is the EEPROM file. There was also no place to specify the fuse and lock bits, required by AVRs.
We explained in email, and attached the EEPROM file.
The First Article chips we got back had only the Flash part programmed.
The second round First Article chips had the EEPROM programmed at the wrong address.
Our supplied EEPROM, in industry standard Intel Hex format, start at 0x0010 not 0x0000 in EEPROM space. Older AVRs have a tendency to corrupt EEPROM address zero.
In conversations about this second failure I was told that the programming equipment used by Digi-Key for the AVRs did not understand Intel Hex format. That the Flash must have origin at zero and EEPROM origin at 0x0800. Not what would be your 0x0810 in Digi-Key world.
After more back and fourth we did get working chips back in October.
We placed an order for more of these in December. I wrote in detail how the chip needed to be programmed based on the information Digi-Key supplied in October. I just check the First Article chips that arrived yesterday. They are useless because exactly the same mistakes were repeated. Apparently my detailed instructions were never read. Only the Flash was programmed. The EEPROM and Lock Bits where not.
Is my only option to get correct chips to make a bogus file that that concatenates the Flash and EEPROM in to a single file? How do I communicate the lock bit settings?
What programming equipment doesn’t understand Intel Hex???
Hello rlpaddock. Welcome to the Forum Community. I’m so sorry that your chips were programmed incorrectly! The best way to have to have the situation rectified is to contact our Customer Service group. You can e-mail them with your invoice number or sales order number and other pertinent information at: customer.service@digikey.com and they will get the situation resolved for you. My apologies for the difficulties and inconvenience you have experienced.
Crazy, the Intel HEX format is well defined, what’s messing up?
https://microchipdeveloper.com/ipe:sqtp-hex-file-format
Start Address is the start (with maybe a defined base offset set in the hex…)
What format was the eeprom file originally generated from? Old Atmel Studio *eep file, MPLAB format, AVRDude, or some other…
Regards,
The .HEX (EEP) file was generated by an ancient version of WinAVR:
:020000040000FA
:05001000600900190069
:0400000500000000F7
:00000001FF
After our First Article chips failed, I was told by Digi-Key, the reason was because we did not supply an EEP file offsetting the file by 0x800 bytes. IE: Flash 0x000 → 0x7FF, EEPROM 0x800 → 0x87F.
A device programmer details of which we could have no knowledge in advance.
Leading to my conclusion that .HEX files were not understood, which made no sense.
I do believe we finally got the issue resolved this morning, and a second set of First Article chips are on the way to us now.
Thank you.
One method of helping Digi-Key get the programming job correct after an incorrect First Article would be to use conventional mailing methods to physically send in a Master Chip.
We used to be able to accept .ELF files to create jobs too but I don’t know if the current operators are familiar with Atmel Studio, otherwise you could also send an .ELF to me or Robert Nelson and we could work with the Programming Center.
But Master Chips are the best method in my experience if Digi-Key has seen issues getting the job correct or if the customer is new to programming AVRs and having difficulty conveying fuse bits.
| Kristof_2649 DigiKey Employee
January 10 |
One method of helping Digi-Key get the programming job correct after an incorrect First Article would be to use conventional mailing methods to physically send in a Master Chip.
We considered that.
Our concern was that the lock bits would not get set correctly, as we’d have to send an unlocked chip.
We used to be able to accept .ELF files to create jobs too but I don’t know if the current operators are familiar with Atmel Studio, otherwise you could also send an .ELF to me or Robert Nelson and we could work with the Programming Center.
Thank you.
if the customer is new to programming AVRs and having difficulty conveying fuse bits.
I can assure that is not the case.
Dig deep enough and you’ll find my name in the credits from the early days of AVR GCC and AVR-LibC.
