| Author |
Message |
|
|
 Posted: Jul 07, 2006 - 12:46 PM |
|
Joined: Aug 13, 2004
Posts: 54
Location: UK
|
|
I have a Mega 128 that I have developed a fairly complex bootloader for, and all seems good apart from RAM allocation. Essentialy I need to make sure that the main application does not trash the bootloaders RAM. How do I tell the startup initialisation code to avoid a range of addreses?
If I place the bootloader RAM at the start of the memory space, and I move the .data/.bss sections of the main app above the area used by the bootloader, will this guarantee the main apps startup code will not touch the bootloader area? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 10, 2006 - 10:51 AM |
|
Joined: Jul 18, 2005
Posts: 33138
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
As the initialisation of RAM in the C startup pre-amble just copies .data initialisers from flash to the start of RAM and then writes 0's to the BSS above this could the bootloader not start by memcpy()ing it's own data to a "safe" location that won't be touched by the .data or .bss of the main app? I was going to suggest copying the data to the end of RAM but, of course, the main app stack will start to grow down from there so maybe just somewhere "near" the end? Another idea is to put a function into the .init1 section. This will be run in the main app BEFORE the C pre-amble so the RAM will be just as the bootloader left it at that point. This would give an opportunity to copy some values into main app visible variables before it gets going.
Cliff |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 10, 2006 - 02:56 PM |
|
Joined: Jan 12, 2002
Posts: 6972
Location: Canada
|
|
You will have to define the limits for RAM in a custom configuratin file. And by the same token write your bootloader to only use that particular segment of RAM. Like for any other device you define a start and end address for RAM. For you r applications it would be one range, out of the m128's full range, and your bootloader would use another.
I must say I am a bit confused as to why you would want this. Bootloaders are meant to only run once in a blue moon, I cant think of any reason why one would want persistant variable data from one session to the next.
If you do need persistant data, why not reserve another block of flash, and store it there? This will protect you against power failures as well. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 10, 2006 - 03:51 PM |
|
Joined: Sep 24, 2001
Posts: 113
|
|
My bootloader and my applciation code share a common eeprom structure up to a certain point. i.e. there is a pre-defined structure, about 6 words long which holds the firmware version, bootloader version, a CRC for the firmware image, etc.
Both the bootloader and the application code can then have common variables accessible to both without either trashing the other one. Of course, its not like RAM, but then RAM is only transient anyway so there's nothing kept in there that is important between bootloader or application sessions. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 24, 2006 - 05:20 PM |
|
Joined: Aug 13, 2004
Posts: 54
Location: UK
|
|
|
glitch wrote:
You will have to define the limits for RAM in a custom configuratin file. And by the same token write your bootloader to only use that particular segment of RAM. Like for any other device you define a start and end address for RAM. For you r applications it would be one range, out of the m128's full range, and your bootloader would use another.
I must say I am a bit confused as to why you would want this. Bootloaders are meant to only run once in a blue moon, I cant think of any reason why one would want persistant variable data from one session to the next.
In this instance the bootloader is run everytime the module is powered up. It performs a CRC on the main application image, if that fails it performs a CRC on the fw download area (upper 30k words of memory) and if that is good it copies it to the lower 30k words of memory and runs it. If bad it stays in the bootloader.
Since memory is very tight, all my comms and timer interrupt functions remain within the bootloader and are accessed by the main application through a jump table in the bootloader to avoid duplication.
I think I have fixed the memory issue, by placing the applications .bss and .data sections after the bootloaders, the application does not seem to stomp on it.
The problem I am now having is that the customer wants comms to start as soon as the module is powered up. I have made this work, apart from when the bootloader jumps to the main app (0x0000). The startup code immediately disables interrupts and I lose bytes.
Just out of interest I set a pin high when I leave the bootloader and clear it when I enter main() so I can measure startup time on a scope. This appears to be almost 300ms with a clock speed of 7.3728MHz which seems a huge amount of time.
I'm just wondering if custom startup code is the only way to go here. If the interrupts are running the incomming data will be buffered by the bootloader code, so the main app can deal with them once it starts up. The bootloader has it's own startup code to initiliase stack etc. so this surely doesn't need to be done twice? |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
