Hello, I'm trying to use __attribute__((at(addr))) to set some data at a fixed point near the end of ROM, and that works, but this operation pads the ROM data area with about 300 bytes after my data. I'm trying to set 16 bytes of data in this specific, absolute area of ROM but don't want the padding. I've tried using scatter-loading with the FIXED modifier in the new region but get the same results. Has anyone seen this as well? If so, did you fix it?
Offending code Whether I use __attribute__((at without modifying the scatter file, or using __attribute__((section and modify the scatter file as indicated, I get the same results. // const unsigned char BootCodeVersionInfo[] __attribute__((at(0x7BE0))) = const unsigned char BootCodeVersionInfo[] __attribute__((section ("version_info"))) = { BOOT_MAJOR_VERSION, BOOT_MINOR_VERSION, ((BOOT_BUILD_VERSION)&0xFF), ((BOOT_BUILD_VERSION>>8)&0xFF), ((BOOT_BUILD_VERSION>>16)&0xFF), ((BOOT_BUILD_VERSION>>24)&0xFF), 0xFF,0xFF, 1,2,3,4,5,6,7,8, }; Scatter file ; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x00001000 0x00007000 { ; load region size_region ER_IROM1 0x00001000 0x00007000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } ER2 0x7BE0 FIXED 0x0030 { *(version_info) } RW_IRAM1 0x20000000 0x00018000 { ; RW data .ANY (+RW +ZI) } } Binary image of ROM area showing padding of zeroes before the blank area of FFs 7BE0 01 05 01 00 00 00 FF FF 01 02 03 04 05 06 07 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 04 03 02 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
This seems to generate reasonable HEX files under 4.71
; ************************************************************* ; *** Scatter-Loading Description File generated by uVision *** ; ************************************************************* LR_IROM1 0x00000000 0x00007BE0 { ; load region size_region ER_IROM1 0x00000000 0x00007BE0 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00018000 { ; RW data .ANY (+RW +ZI) } } LR_IROM2 0x00007BE0 0x00000030 { ER_IROM2 0x00007BE0 0x00000030 { *(version_info) } }
THANK YOU!! This works.
I see then that the answer is to have multiple load regions, not just multiple execution regions. This makes two S-REC files that contain only the data that I want.
If you're ever in Milwaukee, stop by.... Beers are on me !!! =)