Go Down

Topic: AVRDUDE and Mega 2560 Issues (Read 90 times) previous topic - next topic


I have a Mega 2560 and Windows 10 laptop that I am using to interrogate flash, fuses etc using avrdude in both terminal (-t) mode and also using the -U option (ie. -Uflash:r:flashdump.bin:r) to get stuff off the Mega 2560.

I also have a USBasp programmer that plugs into the USB port and connects to the ICSP interface.

Unfortunately I have a range of issues with the results I am seeing.  Have spent a couple of days on this and am getting nowhere.

I am getting very confused about some of the results I am seeing.   If I use AVRDUDE to connect using the interface wiring (-c wiring) then things partially work.   Looking at boards.conf it looks like the wiring interface (basically USB I believe) is used to upload sketches which all works fine with the Arduino IDE - and this is working fine.

If however I use:

avrdude -p m2560 -c wiring -P COM4 -C <config file C:\Program Files...> -t

to put it in interactive mode and:

  - dump flash: always get 0's (always incorrect)
  - lfuse: reports 0xff (this is correct)
  - hfuse: reports 0xd0 (this is correct)
  - efuse: reports 0xff (this is correct)
  - lock: reports 0x10 (should be 0x3f)
  - changing any fuses usually results in an error like 0x10 != 0x3f and reports verification failed.

If I change the avrdude to use -c stk500 it rarely works at all and typically fails to get into interactive mode and has the following errors:

  - multiple stk500v2_ReceiveMessage() errors.

Now if I use the USBasp interface:

avrdude -p m2560 -c usbasp -C <config file> -t

I get the following results:

  - if I use dump flash 0 500 or dump flash 45000 500 I get data this corresponds to my uploaded sketch so all good.
  - if I use avrdude to dump flash (avrdude -p m2560 -c usbasp -C... -Uflash:r:flashdump.bin:r) I get what appears to be the bootloader included in the file created but the loaded sketch is all 0xff.   
  - no matter what format I use to dump flash (Intel = :i, Hex = :h) I always get what I would call a partial flash dump of the bootloader only.
  - looking at any of the fuses works and all values are correct and I can change their values.
  - if I look at flash at address 253952 I see what I think is the bootloader (address equivalent 0x3e000).   

Having tried all the tests already mentioned I have then looked at fuses in case they are causing issues.   The only fuse that appears to be relevant is the lock fuses that control access to memory for bootloader, app etc.   With the settings of 0x3f this appears to allow full access.

I am therefore confused about the following:

1) The Arduino IDE uses the USB alone to upload a sketch, verify it, then run it.   I cannot get the wiring or stk500 interface options with avrdude to even read flash let alone set fuses.   Logically this is working because the Arduino IDE is working.

2) While the USBasp interface works in interactive mode perfectly and I can change fuses & lock and read them fine when the non-terminal mode is entered and a flash dump is done is it only partially correct.

3) If I write the flash read done via USBasp and use USBasp to perform the write I end up with the bootloader being restored which I can see with the flashing LED.   My application is missing however thereby confirming the issue with the flash that was read.

I have Arduino V1.8.8 and this frustration is really spoiling what I have achieved with Arduino so far.   Any help would therefore be much appreciated.

Geoffrey, New Zealand.
Geoffrey Brown, Te Puke, New Zealand.

Go Up