Flashing an ATMega328P/ATMega1284P with an AVRDragon

Hi Christopher,

I've not used the ATmega for a long time, many years (and I too found the tools like genuine AVRisp Mk2 to be unreliable, even the Olimex clone worked better!) so I'm only guessing unfortunately: I'm wondering if it could be this, the command line has the text "lock:w:0x3f" and the first bit of debug has this:

         0xff != 0x3f
avrdude: verification error; content mismatch

According to the ATmega datasheet, only 6 bits in the byte are these 'lock bits', so 0x3f would sound right, if avrdude is functioning. However, the datasheet says that the unused bits in the byte are read as '1', so perhaps avrdude isn't being smart enough to ignore the unused bits, hence it thinks that 0xff is not 0x3f.

Looks like someone had such an issue in Aug 2016: https://github.com/arduino/avrdude-build-script/issues/2

so maybe either the avrdude executable is too old, or they may have changed it so that the command line needs to say "lock:w:0xff" instead of "lock:w:0x3f".

It is crazy though if they changed the CLI so that now it is not backward compatible and all the people who typed 0x3f now have to type 0xff. But sometimes engineers do such irritating things! : (

One of my thoughts was that avrdude was "at fault". However I couldn't find anything to corroborate that theory, I was very close to trying to grab the latest trunk of avrdude to check and it got far too late in the day.

I find the best bugs, as if this is literally being patched now, also. Thanks, I'll see about reverting avrdude and/or trying a patched version, and/or changing the parameters to suit. Damn thing.

There were other faults relating to synchronisation which I was also having, so will likely update if they resurface.

stanto@portableone:/etc/apt$ sudo avrdude -p atmega1284p -P usb -c dragon_isp -U flash:r:flash.bin:r

avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED

avrdude: jtagmkII_getsync(): ISP activation failed, trying debugWire

avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_DEBUGWIRE_SYNC_FAILED

avrdude: failed to sync with the AVR Dragon in ISP mode

avrdude: jtagmkII_close(): timeout/error communicating with programmer (status -1)

 

 

avrdude done.  Thank you.

I came back to working with the hardware, and couldn't talk with the chip again, in fact, I swapped it out for an atmega1284 and re-wired it and this is the type of message I get, still, so even without setting any fuses.

I'm wondering if it is worth trying the AVR Studio capability for programming with AVRDragon, just to rule out CLI and/or avrdude version.

I've not used AVRdragon, but I saw a decent video here, although you probably already may have found this while troubleshooting: https://www.youtube.com/watch?v=yJo29VMXt90

Also, just speculation (I've never used an AVRdragon) I suppose there is also the possibility that the AVRdragon firmware has some mismatch with avrdude or AVR Studio too : (

I don't know if AVRdragon needs upgrading, or even has a way to upgrade.

Also, since avrdude is third party software, it may be better to try the official AVR Studio anyway, since it perhaps may identify if AVRdragon needs upgrading.

Yep, tried the official AVR/Atmel Studio. Still doesn't talk to the chip, Atmel Studio happily upgraded the avrdragon firmware, so that's been re-written. Atmel studio refuses to work with any programmer which has an out of date firmware. Which makes me think there's something wrong with the circuit, but I did wire it up as per the video you also found.

I see : ( I can't think what it could be (assuming it isn't a faulty AVRdragon board). Faulty breadboard maybe? The jumper cables can get faulty too (some of the cheaper ones have broken wires yet where they were badly stripped, yet from the outside they appear fine. But if you've reattempted with new wiring it is unlikely to be that too. It is interesting because the first debug does seem to show that it sometimes almost works, since it recognised that it received 0xff. I'm wondering if it is an intermittent hardware fault that occasionally makes contact.

Also, although it's otherwise a good video, one thing missing there is a 100nF cap directly across the supply rails as close to the ATmega chip as possible. You've probably already done that but if you have not then it could be worth a try. I still have an avrISP Mk2 somewhere, so I can dig that out to attempt this tomorrow too, if I find an ATmega.

Thanks, well I started pulling an atmega out of an arduino to cross-check. I think I'll use this as an opportunity to check the ISP lines with an oscilloscope as well.

Results:

- One atmega1284p is dead

- HVPP let me erase the chip and reset the fuses, the fuse settings had been set in such a way thanks to the avrdude version change that ISP stopped working after trying to flash it

- The sanguinololu board these chips were in has some other fault I'm having to diagnose, the voltage regulator has started overheating and it's bricking the chips when trying to use the FTDI controller to flash it..

sigh.

Thanks for your help!

Hi Christopher,

I see : ( that's unfortunate. Let me know if you need me to try on a breadboard any particular avrdude version, I did manage to find an ATmega chip. But it sounds like you've got identified the root cause, i.e. board fault.

Yeah as you can see, there's an unhappy capacitor...

Still, I had to actually revert to avrdude 5.1 to be able to flash the atmega1284p, when using avrdude 6.3 the program really didn't want to talk with the chip properly

Also the avr dragon is in itself temperamental. Switching out atmega1284ps would sometimes result in a chip not being identified until reseated/some sort of PC reboot/device power cycling dance was performed.

And although I had a spare sanguinololu, attempting to flash the board using avrdude in the arduino IDE wasn't happening at all.

In fact, attempting to flash the atmega1284p via avrdragon as a programmer from the arduino IDE brought up a different problem, the arduino IDE runs avrdude twice in quick succession and the second time will always fail, and so it looks like it overall fails, when this isn't actually the case. The verbose log (and a stack trace) shows that the first instance works, the second instance doesn't work (and this has been checked by manually running the commands) because the avrdragon needs time to settle after the first communication.

So many problems. This is crazy.

As a side note, I did manage to unbrick the atmega328ps which I had been tinkering with. Their fuses were finally reset and the bootloaders reflashed.