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.
(I wanted to reply to this thread, but was not able to: http://www.keil.com/forum/16466/ )
(Using Keil 4.53.0 on an STM32F103VG)
Using two of the methods from that thread to find the "end of ROM":
#pragma arm section rodata = "codeEnd" const unsigned long romCrc = 0xFFFFFFFF; // This is the place for ROM CRC and adding " *.o (codeEnd, +Last)" to the sct file.
extern unsigned int Image$$ER_IROM1$$Limit; codebase = (unsigned int) &Image$$ER_IROM1$$Limit;
the map tells me that codeEnd is at 0x0801275c, and stepping through the code show me codebase is just past the end of romCrc, at 0x08012760.
But the .HEX file produced by Keil ends at 00012A3F, which is 736 bytes longer than the methods above tell me is the "end of ROM". Looking at ROM with the debugger, all the 736 bytes in the .HEX file are indeed loaded into ROM, followed by a few 0xFFs. (But after 0x08013000 the ROM contents become random.)
I don't want to calculate CRC over the whole 1M of ROM when I'm only using 74k. And I don't see how to "0xFF" fill the remaining ROM anyway.
1. If I calculate the CRC over the HEX file, and insert the CRC after that, how will I find the CRC from the code, when it's not at the "end of ROM" by the methods above?
2. Just out of curiousity, what is that extra 736 bytes in the HEX file anyway?
Andrew, please tell me what I am supposed to glean from that link? Things like Image$$RO$$Limit are undefined symbols on my system - that's how I got to Image$$ER_IROM1$$Limit.
I've gotten a suggestion to use Image$$LR_IROM1$$Limit, but that's also an undefined symbol (same for Base, Length, or Size)