Actions
Forum Thread Details
  • Replies 10 replies
  • Subscribers 390 subscribers
  • Views 1837 views
  • Users 0 members are here
Related

Flashing an ATMega328P/ATMega1284P with an AVRDragon

cstanton

This's frustrating.

 

So... push aside your thoughts as to why I'm doing this, and why I'm not doing it via any other fancy method. I'm attempting to do it with an AVRDragon and the chip on the board directly.

 

image

 

I've seen a number of guides on this online. They suggest connecting up a capacitor to the VCC line and a resistor to the RESET line, along with a 16mhz crystal oscillator to the ATMEGA328P chip.

 

It doesn't work.

 

stanto@portableone:/usr/share/arduino/hardware/arduino/bootloaders/optiboot$ make atmega328_isp ISPTOOL=dragon_isp

avrdude  -c dragon_isp -p atmega328p -P usb -b 115200 -e -u -U lock:w:0x3f:m -U efuse:w:0x05:m -U hfuse:w:0xDE:m -U lfuse:w:0xFF:m

 

 

avrdude: AVR device initialized and ready to accept instructions

 

 

Reading | ################################################## | 100% 0.15s

 

 

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: erasing chip

avrdude: reading input file "0x3f"

avrdude: writing lock (1 bytes):

 

 

Writing | ################################################## | 100% 0.06s

 

 

avrdude: 1 bytes of lock written

avrdude: verifying lock memory against 0x3f:

avrdude: load data lock data from input file 0x3f:

avrdude: input file 0x3f contains 1 bytes

avrdude: reading on-chip lock data:

 

 

Reading | ################################################## | 100% 0.05s

 

 

avrdude: verifying ...

avrdude: verification error, first mismatch at byte 0x0000

         0xff != 0x3f

avrdude: verification error; content mismatch

 

 

avrdude done.  Thank you.

 

 

Makefile:427: recipe for target 'isp' failed

make: *** [isp] Error 1

This is when I'm lucky. When I'm not so lucky I get this:

 

stanto@portableone:/usr/share/arduino/hardware/arduino/bootloaders/optiboot$ make atmega328_isp ISPTOOL=dragon_isp

avrdude  -c dragon_isp -p atmega328p -P usb -b 115200 -e -u -U lock:w:0x3f:m -U efuse:w:0x05:m -U hfuse:w:0xDE:m -U lfuse:w:0xFF:m

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 done.  Thank you.

 

 

Makefile:427: recipe for target 'isp' failed

make: *** [isp] Error 1

What am I missing or doing wrong?

 

I've also had similar problems using an AVRISPmk2, and also trying to program an ATMEGA1284P, so I suspect there's something "obvious" I'm missing, or a step, and no matter how much I search all it says is that I should have an oscillator and cap. Gah.

 

Tips? Even if it's a step by step from scratch..

Parents

  • 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".

    image

    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! : (

  • in reply to shabaz

    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.

Reply
  • in reply to shabaz

    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.

Children
No Data