Porting ATMEGA1280 Bootloader to ATMEGA2560 -- Wrong Location!

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

Hi -- I have the screamer bootloader that works great on 1280 chips, but since these are hard to find right now, I'm trying to port the bootloader so it works with the easier to find 2560's.  

 

I see I can set my fuses for the M2560 to keep my BOOTSZ flashsize=2048 (start address $1F800) to match the M1280 -- so I did that.

 

In my makefile for the M1280 I have:

LDSECTION  = --section-start=.text=0x1F000

 

Can I keep it there or do I need to use the Boot Flash size = 4096 and address 0x3E000?

 

However, when I program using avr-gcc (WinAVR 20100110) 4.3.3:

It does not write the bootloader in the correct location see section below (after :020000023000CC is blank):

 

:020000023000CC
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80

 

 

It's placing it at the top:

 

:100000000C9472000C9493000C9493000C94930045
:100010000C9493000C9493000C9493000C94930014
:100020000C9493000C9493000C9493000C94930004
:100030000C9493000C9493000C9493000C949300F4
:100040000C9493000C9493000C9493000C949300E4
:100050000C9493000C9493000C9493000C949300D4
:100060000C9493000C9493000C9493000C949300C4
:100070000C9493000C9493000C9493000C949300B4
:100080000C9493000C9493000C9493000C949300A4
:100090000C9493000C9493000C9493000C94930094
:1000A0000C9493000C9493000C9493000C94930084
:1000B0000C9493000C9493000C9493000C94930074
:1000C0000C9493000C9493000C9493000C94930064
:1000D0000C9493000C9493000C9493000C94930054
...

 

I've been reading and trying all sorts of things... I can get it to program the bootloader hex file directly and it runs... but then I cannot update the app/program.  

 

Doing other things, like changing to Boot Flash Size = 4096, then programing bootloader on the ATMEGA2560 I can update the app, but it won't start (stuck in bootloader forever).  

However, flipping HFuse from D8 to D9 goes between bootloader and program...

I'm obviously doing something wrong, I just need some encouragement and guidance... 

 

Thanks!

Last Edited: Sun. Oct 10, 2021 - 05:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How can a section start to 1F000 be right for a 256K chip? Think about it, 256K is 0x40000. A. Bootloader is going to be 1/2/4/8K below there. Say it is 4K that is 0x1000 then 0x40000 - 0x1000 is 0x3F000. By the same token an 8K bootloader (0x2000) is going to be 0x3E000. So your section start is going to be a five digit Hex number starting with a 3.

 

Don't be fooled by Atmel's madness where they measure flash sizes in 16bit words not bytes. The avr-gcc Toolchain does everything in bytes. 

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

 

Got it, still not working property... I'm now using:

 

LDSECTION  = --section-start=.text=0x3E000

 

Fuses:

 

Makefile generate elf:

Linking: Bootloader_ATmega2560.elf
avr-gcc -mmcu=atmega2560 -I. -gdwarf-2 -DF_CPU=16000000UL  -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=Bootloader_ATmega2560.o  -std =gnu99 -MD -MP -MF .dep/Bootloader_ATmega2560.elf.d Bootloader_ATmega2560.o --output R Bootloader_ATmega2560.elf -Wl,--section-start=.text=0x3E000

 

Program:

C:\Documents and Settings\Administrator\Desktop\Wireless_Bootloader_ATmega328\MEGA2560>avrdude -p m2560 -c avrispmkii -D -U flash:w:Bootloader_ATmega2560.hex:i
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e9801
avrdude: reading input file "Bootloader_ATmega2560.hex"
avrdude: writing flash (254934 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 254934 bytes of flash written
avrdude: verifying flash memory against Bootloader_ATmega2560.hex:
avrdude: load data flash data from input file Bootloader_ATmega2560.hex:
avrdude: input file Bootloader_ATmega2560.hex contains 254934 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: 254934 bytes of flash verified
avrdude: safemode: Fuses OK (E:FD, H:D8, L:FF)
avrdude done.  Thank you.

 

Dump of flash:

 

   Bootloader is now at this location -- boots into bootloader OK!

 

:020000023000CC
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00 << NOT AT THE LOCATION I'D THINK IT SHOULD BE AT...
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10DFE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF41
:10DFF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF31
:10E000000D9472F00D9493F00D9493F00D9493F0A1  << IT'S FURTHER DOWN...
:10E010000D9493F00D9493F00D9493F00D9493F070
:10E020000D9493F00D9493F00D9493F00D9493F060
:10E030000D9493F00D9493F00D9493F00D9493F050
:10E040000D9493F00D9493F00D9493F00D9493F040
:10E050000D9493F00D9493F00D9493F00D9493F030
:10E060000D9493F00D9493F00D9493F00D9493F020
:10E070000D9493F00D9493F00D9493F00D9493F010

Program area is empty (seems good so far!!):

:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE0
:10003000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD0
:10004000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC0
:10005000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB0
:10006000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA0
:10007000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF90
:10008000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF80
:10009000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF70
:1000A000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF60
:1000B000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF50
:1000C000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF40

 

When I send it app/program -- it uploaded ok!:

:10000000F4C0000004C1000002C1000000C10000F3
:10001000FEC00000FCC00000FAC00000F8C00000F4
:10002000F6C00000F4C00000F2C00000F0C0000004
:10003000EEC00000ECC00000EAC00000E8C0000014
:10004000E6C00000E4C00000E2C00000E0C0000024
:10005000DEC00000DCC00000DAC00000B9C1000052
:10006000D6C00000D4C00000D2C00000D0C0000044
:10007000CEC00000CCC00000CAC00000C8C0000054
:10008000C6C00000C4C00000C2C00000C0C0000064
:10009000BEC00000BCC00000BAC00000B8C0000074
:1000A000B6C00000B4C00000B2C00000B0C0000084
:1000B000AEC00000ACC00000AAC00000A8C0000094
:1000C000A6C00000A4C00000A2C00000A0C00000A4
:1000D0009EC000009CC000009AC0000098C00000B4
:1000E00096C0000000002100240027002A002D00F7
:1000F0003000330001010000040107010A01000083
:100100002200250028002B002E00310034000201B

 

PROBLEM: 

 

M2560 is still stuck in bootloader... is this the correct command to jump to start?

void (*app_start)(void) = 0x0000;

 

At this point, if I change the HFuse to D9 program works but cannot enter bootloader... If I set to D8 bootloader works, but cannot start app.  

Last Edited: Sun. Oct 10, 2021 - 08:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How can the bootloader Hex be 256k bytes long? It should be 4K or 8K or something. Sounds like some part of it has not made the jump to the BLS. 

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

Makes sense. Where would you suggest I look…could it be my AVR-gcc that is out of date or my code?  This all worked fine on a 1280.

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

Do you have any non standard section names? Also what does your objcopy look like? Are you using -R's or - J's?

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

Mavromatis wrote:
is this the correct command to jump to start?
just code a 24 bit JMP. 

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

Yes, -R & -j (makefile attached)

# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
	@echo
	@echo $(MSG_FLASH) $@
	$(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@

%.eep: %.elf
	@echo
	@echo $(MSG_EEPROM) $@
	-$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
	--change-section-lma .eeprom=0 -O $(FORMAT) $< $@

 

Attachment(s): 

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

clawson wrote:

Mavromatis wrote:
is this the correct command to jump to start?
just code a 24 bit JMP. 

 

void (*app_start)(void) = (void *)0x000000;

didn't seem to make a difference... however, changing the HFuse to D9 runs the code.  Back to D8, it runs the bootloader...

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

Mavromatis wrote:
Yes, -R & -j (makefile attached)

Just to give you an idea this is what Studio 7 does for creating .hex:

 

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "cpp_app.elf" "cpp_app.hex"

a few more -R than you have.

 

For the .eep you seem to basically agree with what they have:

"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "cpp_app.elf" "cpp_app.eep" || exit 0

 

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


clawson wrote:

a few more -R than you have.

...and you need one of these, matey:

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Possibly the 2560's need extended calls or jumps and the 1280's do not.

128KB = 64KW fits into a 16-bit Z register.

Moderation in all things. -- ancient proverb

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

I'm going to keep this as a 1280 project for now... thought it would be fairly straight forward.  Once I get more time, I'll dig deeper into it and try to port it...  Even if I get the bootloader working, I'll need to recompile the bits to work on a 2560 making my OTA updater need to handle two different binaries.

 

 

Thanks for now.