(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?