The Overlay mechanism implemented by Keil is ingenious. Moreover if we want add some functionnality in Eeprom without change ROM code is to my mind impossible because DATA GROUP area will be modified with new local variables used in our new functions in Eeprom. What do you think about this?
Thanks a lot,
But i think the concept is incorrect. The code in ROM should (must?) have a data space separate from the code in EEPROM/FLASH.
I don't think you can ask a compiler or linker to maintain variables in one spot over whatever changes may be made in the future. Suppose a module is completely eliminated; would you want to maintain the variables it used in memory to maintain compatibility? I don't think so.
What you are dealing with here essentially is the ability to download code and execute it independent of the code in ROM.
The only other way to do this is to fix the locations of memory. This can be done using the _at_ option when declaring a variable. This is very un flexible, which is really the point I'm trying to make. The compiler/linker shouldn't be in charge of this decision. It is up to the developer to recognize the problem and address it.
One idea is to make the ROM code a library, whose segments are at fixed addresses. If the system wakes up in the ROM code, then the 1st call to the EEPROM has to fix the stack pointer. This scheme will not overlay the data segments of the program as a whole, but should allow the ROM data segments to be overlayed and the EEPROM data segments overlayed. Of course the entry points into the EEPROM are at fixed locations.
There are a lot of people already doing this kind of stuff. To do this, you must be very careful and thoughtfully design your interfaces (ROM-EEPROM).
I've come up with the following list of tips and suggestions. Note that I would create 2 separate programs: one for the ROM portion and one for the EEPROM portion. Here are my assumptions:
1. ROM goes from 0x0000-0x7FFF.
2. EEPROM goes from 0x8000-0xFFFF.
3. A call-table will be generated in the EEPROM to provide addresses for functions in EEPROM called from ROM.
4. ROM functions can call EEPROM functions but not vice-versa.
The ROM Program...
1. The ROM program will be fixed. It will not change and so the EEPROM must work around it.
2. Note the last used DATA address for the ROM area.
3. Locate the stack pointer at 0x80. The space between the last data address (noted in step 2) and 0x7F may be used by the EEPROM program.
4. Do not include the EEPROM code in the ROM project. Instead, create a call table (that will be located in the EEPROM) using the function names (for the functions in EEPROM). For example:
cseg at 0x8000
func_1_redirect: ljmp func_1
func_2_redirect: ljmp func_2
"If you were to take a look at different strategies for symbol table management algorithms ...."
I am not concerned with that, that is a coding issue. Any algorithm can be used with assigning addresses in the sequence they exist in a module, rather than some other way.
View all questions in Keil forum