Over the weekend I received the jumpers for connecting the recently acquired AVR Dragon, so I decided to give it a go this weekend. Because the chips I’m using are programmed to use an external clock, the best programming mode for writing chips stand-alone is High-Voltage Parallel Programming, which doesn’t rely on an external clock.
After jumpering the board for HVPP per the SCKT3200A2 devicesheet in the official AVR Dragon documentation I tried it out on both OS X and XP, and it mostly works well, except for programming the EEPROM. For some reason, EEPROM seems to just not write, and thus validation fails. If I insert a chip with EPROM already programmed properly, validation will work, so reading is definitely working and nothing is (even partially) overwriting the existing data.
There are no problems writing the Flash or fuses, and since writing to both Flash and EEPROM use the same lines, I don’t think it’s something mis-jumpered. Nor do I believe the problem is the chip itself, since I’ve tried multiple chips which can be programmed in an STK200 (parallel port bitbang) programmer.
Here’s the command lines used with the AVR Dragon which errors while validating the EEPROM:
avrdude -p m8 -P usb -c dragon_pp -U lfuse:w:0x3f:m -U hfuse:w:0xdf:m -U flash:w:SDrive.hex:i -U eeprom:w:SDrive.eep:i
Here’s the one used with the STK200 clone, the same chip, and the same version of avrdude, which works just fine:
avrdude -p m8 -c stk200 -U lfuse:w:0x3f:m -U hfuse:w:0xdf:m -U flash:w:SDrive.hex:i -U eeprom:w:SDrive.eep:i
Here’s the actual error:
[Working stuff here cut...]
avrdude: verifying ...
avrdude: 8084 bytes of flash verified
avrdude: reading input file "SDrive.eep"
avrdude: writing eeprom (329 bytes):Writing | ################################################## | 100% 36.51s
avrdude: 329 bytes of eeprom written
avrdude: verifying eeprom memory against SDrive.eep:
avrdude: load data eeprom data from input file SDrive.eep:
avrdude: input file SDrive.eep contains 329 bytes
avrdude: reading on-chip eeprom data:Reading | ################################################## | 100% 33.60s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x72 != 0xff
avrdude: verification error; content mismatchavrdude: safemode: Fuses OK
avrdude done. Thank you.
If anyone has an idea as to what might be wrong here, I’d love to hear it. This is exactly the same problem I get on both Windows XP (avrdude v5.6 from WinAVR-20081205) and OS X (avrdude v5.5 from AVRMacPack).
For what it’s worth, I have posted this here on the AVR Freaks forum, but it doesn’t seem to be receiving any replies.
UPDATE: It seems that this is a problem with avrdude. I can program the chip with no problem in HVPP mode using AVR Studio. This would be a good time to have a logic analyzer. Maybe I could actually fix the problem.
When I was trying to reprogram my Fuzebox with ladyada’s USBTinyISP programmer, I had lots of issues. I was able to use the avrdude raw mode to try some things out — it puts you at a command prompt and you can write six byte sequences and get the response echoed to you. With that board, it ended up being a problem with pull-up resistors on the programmer interfering with the signal. However, since you’re getting valid communication, it’s probably something more tricky, an actual protocol issue.
Ben: That’s my concern… I’ve got no problems writing the fuses nor the flash, all of which are done over the same set of pins as the EEPROM stuff. So, I don’t think it’s at that layer. I’ve been poking around the avrdude source and there’s only one relatively small section (16 lines or so in STK500v2.c) which apply to the AVR Dragon when programming the EEPROM in HV mode. Now I’m just fighting with getting avrdude compiling so that I can try some changes. Unfortunately libusb on OS X is giving me headaches. I’m hoping that I can get further on it tonight.
(Also, the programmer works great with AVR Studio… Something is definitely broken in avrdude.)