ATMEGA48P Memory issues (SOLVED)

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

Hello everyone,

 

For our needs, we have built a custom UART bootloader and a bunch of applications for ATMEGA48P devices. Right now everything is fine ! The flash memory mapping is as follow:

- application (0x0000 up to 0x0D80)

- bootloader (0x0D80 up to the end)

      Program: 624 bytes

      Data: 72 bytes

 

However, we observe a strange behaviour:

- when the application binary size is below 3KB, everything is fine, we can jump from application to bootloader and back to the application.

- when the application binary is above 3KB, the application doesn't jump in the bootloader anymore (ie. application doesn't overlap bootloader).

Example with the same firmware (with or without some size optimization in GCC compilation command)

Good_FW:

    Program: 2604 bytes

    Data: 201 bytes

Bad_FW:

    Program: 2998 bytes

    Data: 201 bytes

 

Nota: the "Bad_FW" is usable, we can use it to do everything except jump back to the bootloader !

         debugging the firmware is a bit tricky with the debug wire and the code is compiled in both cases with the -Os option

 

 Does anyone has ideas or hints to circle this issue in order to use the maximum size allowed for the application.

 

Best regards,

 

This topic has a solution.
Last Edited: Tue. Aug 1, 2017 - 08:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As it is a 48 (so no bootloader section) how do you build and program the two pieces? Is this all in one project or are the bootloader and the app built separately? if yes then how do you combine the two hex to program everything in?

 

As you say 3,072 is 0xC00 so there's no reason this should impact on something located at 0xD80.

 

How do you accomplish the jump to bootloader? Presumably an RJMP or an RCALL? If so then how do you calculate the relative offset to be used ?

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

Hello clawson,

 

The bootloader is written in the flash memory with the avrdude tool (.hex file). When compiled, we use the --start-section=.text flag of GCC to relocate the code to the 0xD80 base address.

For the application, we use our bootloader to transfer data between uart buffer to flash pages. We perform an erase and write page per page.

 

The jump to the bootloader is done via a trick I found on the forum: (((void(*)(void))BOOT_ADDRESS)());

Where BOOT_ADDRESS is defined to 0xD80 and used as a GCC argument -DBOOT_ADDRESS=0xD80. Using this trick I don't need to handle the relative jump to

the correct address according to the application size.

 

Best regards,

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

Hello all,

 

I finally found the solution to my problem. Like the ATMEGA2560, when you write the flash, you need to do a power cycle in order to reset the microcontroller.

The issue I was facing is only visible when you write the flash and try to re-write the flash without power-cycling the board.

 

Now everything works fine !

 

Best regards,

Last Edited: Tue. Aug 1, 2017 - 08:01 AM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

cfauvel wrote:
Now everything works fine !
I doubt that.

 

The actual problem is this:

cfauvel wrote:
Where BOOT_ADDRESS is defined to 0xD80 and used as a GCC argument -DBOOT_ADDRESS=0xD80
You need the word address there. With 0xD80 the jump will end up at 0xD80 * 2 - 0x1000 = 0xA10. Whether it works with the wrong jump or not depends on the content from there to the real begin of the bootloader. E.g. empty Flash will work. 

Stefan Ernst

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

Hello sternst,

 

Without changing the BOOT_ADDRESS offset, I have had some lucky tries but it wasn't the solution.

You are right,  the correct address must be 0x6C0 and it's working now without power cycling the board.

Thank you for your quick reply.

 

Best regards,

Last Edited: Tue. Aug 1, 2017 - 08:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about no bootloader support in mega48? Is it a myth?
.
MG

I don't know why I'm still doing this hobby

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

MicroGyro wrote:
Is it a myth? .
Yes it's a myth.

 

What the mega48 (and all small AVR) lack is a separate, protectable "bootloader section" and the BOOTSZ and BOOTRST fuses to go with it. So they always start execution at 0x0000. But unlike big AVR that have those things the SPM execution restriction is lifted. It can be done from anywhere in the address space. The only stumbling block for a bootloader in these small devices is that because entry is at 0 then the jump there has to be to the bootloader entry point. If the app is later updated and that includes reprogramming flash page 0 then the RJMP up to the bootloader must be maintained.

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

clawson wrote:

MicroGyro wrote:
Is it a myth? .
Yes it's a myth.

 

What the mega48 (and all small AVR) lack is a separate, protectable "bootloader section" and the BOOTSZ and BOOTRST fuses to go with it. So they always start execution at 0x0000. But unlike big AVR that have those things the SPM execution restriction is lifted. It can be done from anywhere in the address space. The only stumbling block for a bootloader in these small devices is that because entry is at 0 then the jump there has to be to the bootloader entry point. If the app is later updated and that includes reprogramming flash page 0 then the RJMP up to the bootloader must be maintained.


Well I should try this.
Thank you Sir.
.
MG

I don't know why I'm still doing this hobby

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

Not to hijack the thread (but OP may be interested anyway) but this explains the issues and how to solve them for bootloaders on small AVR:

 

http://jtxp.org/tech/tinysafeboo...

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

clawson wrote:

Not to hijack the thread (but OP may be interested anyway) but this explains the issues and how to solve them for bootloaders on small AVR:

 

http://jtxp.org/tech/tinysafeboot_en.htm


Bookmarked!
.
MG

I don't know why I'm still doing this hobby