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.
Hello I am wanting to place a checksum at the end of the flash image. I have a crc.c that only has this array - where I will manually replace xx and yy with the 16bit CRC, once I have made a .bin image. (...wish there was a way for the compiler to do this automatically)
const unsigned char __attribute__((aligned (16)))ucCRC[16] = { ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', 'C', 'R', 'C', 'xx', 'yy' };
Using the Scatter-Loading Description File I have this
; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x08040000 0x000B00000 { ; load region size_region ER_IROM1 0x08040000 0x000B00000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM2 0x10000000 0x00010000 { ; RW data kLokIram2.o(+RW +ZI) ttydebugout.o(+RW +ZI) ttydebugin.o(+RW +ZI) } RW_IRAM1 0x20000000 0x00020000 { ; RW data .ANY (+RW +ZI) } }
Without manually placing each .o section, how do I place the crc.o or ucCRC[16] after the .ANY (+RO) in the ER_IROM1 region? I tried crc.o (+RO, +Last) - but the linker does not allow that - error: L6235E: More than one section matches selector - cannot all be FIRST/LAST.FIRST/LAST. Any help would be much appreciated
You've got an 11MB Flash?
Thoughts, shrink IROM1, and create a 16 byte IROM2 sector AFTER IROM1, not inside it.
const unsigned char *ucCRC = (unsigned char *)0x08B40000;
Keil tools expect you to create post-link user functionality to sign/package the linker output in a form that uniquely suits your needs/requirements.
This forum really needs registration, and editing...
const unsigned char *ucCRC = (unsigned char *)0x08B3FFF0; // 16-byte prior to end-of-flash
Perhaps I am not making myself clear. The flash is located at that address in a STM32F417 memory map. I could readily declare -
const unsigned char __attribute__((at(0x08B3FFF0)))ucCRC[16] = { ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', 'C', 'R', 'C', ' ', ' ' };
and the linker would place it there... That is not what I want - I want to place ucCRC[] at the end of the application code + RO data, about 200K bytes worth.
Please elaborate on your "This forum really needs registration, and editing..." - I do not understand such a comment - I thought that this was a forum to assist users of Keil products?
Um, let's think about that, if I could edit my posts I could correct inaccuracies instead of posting a second one correcting the first.
For example your STM32F417 does not have 11MB (0xB00000) of FLASH.
crc.c
main.c
extern const unsigned char ucCRC[16];
project.sct
LR_IROM1 0x08040000 0x000B0000 { ; load region size_region ER_IROM1 0x08040000 0x000B0000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00020000 { ; RW data .ANY (+RW +ZI) } } LR_IROM1_END +0 0x10 { ER_IROM1_END +0 0x10 { crc.o (*, +Last) } }
out.bin
00000000 : 20 04 00 20 9D 01 04 08 - A3 04 04 08 9F 04 04 08 .. ............ 00000010 : A1 04 04 08 CF 03 04 08 - E1 06 04 08 00 00 00 00 ................ 00000020 : 00 00 00 00 00 00 00 00 - 00 00 00 00 D9 05 04 08 ................ 00000030 : D1 03 04 08 00 00 00 00 - 29 05 04 08 8D 06 04 08 ........)....... 00000040 : B7 01 04 08 B7 01 04 08 - B7 01 04 08 B7 01 04 08 ................ 00000050 : B7 01 04 08 B7 01 04 08 - B7 01 04 08 B7 01 04 08 ................ .. 00000710 : 38 BD 00 00 FF F7 5E FE - 00 20 FF F7 1F FF 00 20 8.....^.. ..... 00000720 : FF F7 40 FF FF F7 BE FE - FF F7 5C FD 01 48 00 F0 ..@.......\..H.. 00000730 : 03 F8 FE E7 C0 07 04 08 - 10 B5 04 46 01 E0 FF F7 ...........F.... 00000740 : DF FF 14 F8 01 0B 04 49 - 00 28 F8 D1 BD E8 10 40 .......I.(.....@ 00000750 : 0A 20 FF F7 D5 BF 00 00 - 1C 00 00 20 00 00 06 00 . ......... .... 00000760 : 01 00 01 00 01 00 00 00 - 00 10 00 20 00 40 00 80 ........... .@.. 00000770 : 08 00 00 00 08 00 00 00 - 08 00 00 00 08 00 00 00 ................ 00000780 : A0 07 04 08 00 00 00 20 - 20 00 00 00 E2 06 04 08 ....... ....... 00000790 : C0 07 04 08 20 00 00 20 - 00 04 00 00 F2 06 04 08 .... .. ........ 000007A0 : 00 00 00 00 00 00 00 00 - 00 00 02 40 00 0C 02 40 ...........@...@ 000007B0 : 00 0C 02 40 00 0C 02 40 - 00 0C 02 40 00 00 00 00 ...@...@...@.... 000007C0 : 20 20 20 20 20 20 20 20 - 20 20 20 43 52 43 78 79 CRCxy
That's what I was looking for - thanks Pier - and yes that 0x000B00000 was a bit of a typo. Much appreciated.