We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi All
Does anyone know how the Region$$Table$$Base / Region$$Table$$Limit and region table works? (Cortex M4 project causing problems...)
Normally the Keil initialisation routines uses these to initialise variables (.data and .bss at least) but in this project the initialisation needs to be performed without these start-up files and at the moment is is not operating correctly and the content doesn't make full sense.
1) The table (in this example case) consists of 8 long words. The first three look quite obvious, being: - source location (in FLASH) to be copied to initialised data - destination location (in RAM to be initialised) - length (the number of bytes to be initialised) - the final long word's meaning is not known - maybe there are some flags or it has some special address (?)
2) Comparing the table's content with the map file it seems to make half-sense: - the RAM addresses match the start of .data and .bss area - the lengths of these ares are also correct in both cases - the source location to be used for the initialised variables copy looks good - it is (in this case) just after the region table, which is itself just after the code and consts. - it is not clear what the 4th long word is for in each case. I thought that it may be flagging whether the area is to be zero filled or copied, but, in any case, it looks as though the final block is thee one to be zero filled.
3) The big problem is that there are 174 initialised bytes to be copied but there are only 84 bytes of initialised data in the file just following the region table. The result is that 174 bytes are copied from FLASH to initialised data but only the first 84 of them have values - the rest are set to 0xff (since Flash is empty and nothing else exists there) The first variables which are copied also don't match the expected values.
4) I find the following in the map file:
Code (inc. data) RO Data RW Data ZI Data Debug
21550 1246 1846 372 1832 317460 Grand Totals
21550 1246 1846 84 1832 317460 ELF Image Totals (compressed)
21550 1246 1846 84 0 0 ROM Totals
Here the 84 byte size is seen and also there is the (compressed) in brackets.
Does this mean that the data is stored in a compressed from and need to be decompressed when copying?
Any ideas?
Regards
Mark
Why do you need to perform the initialization without the startup files? Note that startup files are normally used both when writing boot loaders and when writing applications started from boot loaders.
So what is your special case, where the startup files aren't suitable for use?
Hi
I don't remember in detail at the moment.
In the meantime I have found that there is indeed a decompression performed by the initialisation code and am trying to build the _main() call back in so that it will automatically handle this. I will probably realise why it was removed previously while working through the process [I think that I remember it working with stacks differently and bypassing the initialisation solved things in the past, plus, parsing the region table also allowed access to some memory details needed for other things (which couldn't be solved with more conventional methods - have more experience with IAR, GCC and Rowley than Keil uVision)].
The other solution was OK on LPC (ARM7 and Cortex M3), STR9 (ARM9), Stellaris (Cortex M3), ATMEL ARM7 in the past but it may be the new uVision4 that adds the compression(?). Or maybe the Kinetis Cortex M4 (working on at the moment) is the difference(?).
I'll report back in case I have a good explanation or run into any brick walls with the _main() approach.