Bootloader, OS-X, avrdude, 2560, Olimex.

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Experimenting with a USBasploader type bootloader for a standalone 2561 project but testing on an Arduino MEGA.

Avrdude version 6.3 (from platformio), Mac OS-X 10.13.6, programmer is Olimex stk500v2 (DB25 back shell, LED but no push button).

No connection problems and programs reliably. Problem is what is actually programmed and read back.

While testing the bootloader I noticed it appeared twice in th the 256k address space, where it should be at the top, and again at about 128k.

Created a 256k random intel hex format file and wrote it, it writes but verify fails.

Reading the flash back and comparing it to what was written is odd. The first 64k byte block is correct, second 64k block doesn't match, third 64k block is correct, fourth 64k block doesn't match but is same as the second block. The two identical bad blocks don't match any of the write file blocks.

What is going on, is it the programmer, is it avrdude or its conf?

Hope to learn a bit more on the weekend when I can borrow a 'real' avr programmer.

Any assistance apprecicated.

 

Ken.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR's use 16 bit words for flash memory addressing, while most tools (gcc, avrdude, etc) use 8 bit byte addresses, are you confusing the two which is a common AVR beginners mistake?

I can assure you the USBasp programmer and avrdude are both good tools to use for atmegas and are in common use.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

I can assure you the USBasp programmer and avrdude are both good tools to use for atmegas and are in common use.

 

No USBasp programmer involved, using an Olimex stk500v2 programmer to install a bootloader into a Atmega2560, the bootloader is USBasploader. There are many versions of USBasploader on git hub, the one I selected has good configuration options and worked first time on 328 but not 2560.

 

Quote:

AVR's use 16 bit words for flash memory addressing, while most tools (gcc, avrdude, etc) use 8 bit byte addresses, are you confusing the two which is a common AVR beginners mistake?

 

Not confused, I've worked with computers with 16 bit words, 8 bit word and even 12 bit words. Doesn't make any difference to the problem, flash memory can be looked at as 256k of 8 bit bytes with 8192 bytes of bootloader at 0x3E000 or 128k of 16 bit words with 4096 words at 0X1F000.

 

Which ever way you look at the memory, the bootloader should appear only where it's supposed to be, at the top of memory, not at the top but also duplicated in the middle of memory as well.   

 

redken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

redken wrote:
Experimenting with a USBasploader type bootloader for a standalone 2561 project but testing on an Arduino MEGA.

 

The Arduino IDE uses avrdude to program the Arduino bootloader.

Why not have the Arduino IDE program the Arduino bootloader and capture the avrdude command line that it generates?

Also, compare the Arduino bootloader hex file against your bootlaoder hex file. 

See how the Arduino bootloader hex file handles the addressing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck beat me to it, that was where I was going next, a gazion Megas satisfied. 
big megas have an additional ramps reg the 328 does not that needs to be handled properly by the boot loader.

there are freaks here that know bootloaders much better then I, wait a day, most are asleep at this hour.
jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

Last Edited: Fri. Dec 6, 2019 - 04:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I modified my intel hex generator to use the same extended address format as the Arduino 2560 bootloader and no change.

 

The confusion is that for files larger than 64k bytes an avrdude read produces intel hex files with an "Extended Linear Address Record" but files from avr-objcopy (which is used to convert ELF to intel hex) use an "Extended Segment Address Record".

 

In the end it makes no difference when writing to a device, avrdude is happy with either format.

 

I used Arduino IDE (1.8.10) to write "stk500boot_v2_mega2560.hex" to an Arduino MEGA and again it appears at top of flash and midway through the flash.

 

ki0bk wrote:

big megas have an additional ramps reg the 328 does not that needs to be handled properly by the boot loader.

 

Yes, a) the bootloader on the MEGA (USBasploader in this case) should handle all that when it's writing the application program to flash but I'm not yet executing USBasploader, and b) avrdude handles it when it's installing a bootloader which is what I'm doing. This would suggests a major avrdude bug which I'm sure would have been found by now.

 

I'm no further advanced, I've learnt a lot but still have one too many bootloaders in flash.

 

Starting to think the problem might be the Olimex programmer.

 

redken.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There was some version of avrdude where a bootloader above 64K issue was fixed. Can't remember anything about the problem or when but I wonder if you have the wrong version of avrdude?

 

(I'm sure the Git/Bugzilla historyt of avrdude will reveal more about the problem/solution)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at bug histories around avrdude 6.0.1 there was a problem writing to devices  > 128k which was fixed in 6.1. 

 

I'm using 6.3 which is supposed to be good to 256k. 

 

Get access to a different programmer later today which may behave differently/better.

 

redken

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Avrdude and Atmel jtag ice3 programmer work perfectly on Arduino MEGA 2560, no duplicated bootstrap, no duplicated application, all good.

Flashing a bootstrap with Olimex AVR-ISP500 works too, no verify error, and a read back with Atmel programmer shows the bootstrap in the correct place with no duplication. However a read back with the Olimex programer has the bootstrap in two places.

Edit to correct previous post:

With the Atmel programmer writing a 256k file of random data and reading back all 64k blocks match, reading back with Olimex has the duplicated 2nd and 4th 64k blocks.

With the Olimex programmer writing a 256k file of random data and reading it back the 2nd and 4th blocks mismatch and are not identical, reading back with Atmel shows 2nd block to be all 0xFF and in the 4th block all bytes mismatch .

Also, there seems to differences between writing small (bootstrap size) files and large 256k files.

redken 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0