I have a board with a SPI flash chip on it, and via a UART it can receive a BIN file plus metadata and write it to the SPI flash chip. This is all done with an app that starts at the 2nd sector of MCU flash (it's this same code that uses the UART to download apps for the bootstrap loader), and I have another app, a bootloader, that uses IAP calls to sector by sector erase/copy the BIN part of the app in SPI flash to MCU flash and then branch to this 'downloaded' app, and it runs fine, but *only* if I manually strip the beginning of the BIN file out before downloading it via the UART and getting it into the SPI flash chip.
This beginning is 0x1D00 0xFF's, and after that is the code that loads the SP and branches around all the INT vectors to the startup code.
I use the project's linker options and specify to use the memory layout from Target Dialog, and specify my app start address (0x2000) and configure the start/size of the address range in the debugger flash download dialog similarly.
The problem I have is that when I take my HEX file and convert it to a BIN file it has 0xFF's from address 0 to 0x1D00, and the next 8 bytes are what I expected at the RESET vector to load the SP and then jump past all the INT vectors to where the RESET startup code is.
So, if I copy this BIN file (plus metadata) to my SPI flash and reboot, and let the bootstrap loader get the BIN file into MCU flash at 0x2000 and then branch there it crashes. However, if I post-process the BIN file to strip out all the leading 0xFF's up to 0x1D00 and then get that into my SPI flash, then when the MCU is reset and the bootloader copies the file to 0x2000 and branches to it everything works fine.
So... what I can't figure out is (1) where these 0x1D00 0xFF's are coming from and ending up in the beginning of my HEX/BIN files; and (2) how to get my app to build without them. Google has not been very helpful in helping me resolve this.
FWIW, my MCU is an LPC1752.
Help... Dave
I found the offending address in the map file
.ARM.__at_0x02FC 0x000002fc Section 4 lpc17xx_startup.o(.ARM.__at_0x02FC)
which seems to be associated with this in the default startup ASM file
IF :LNOT::DEF:NO_CRP AREA |.ARM.__at_0x02FC|, CODE, READONLY CRP_Key DCD 0xFFFFFFFF ENDIF
which made the start of the HEX file like this
:020000040000FA :0402FC00FFFFFFFF02 :020000040000FA :1020000000400010E1770000E9770000EB77000066 :10201000ED770000EF770000F1770000000000008E
Thankfully, adding NO_CRP to the assembler defines changes the HEX file to this
:020000040000FA :1020000000400010E1770000E9770000EB77000066 :10201000ED770000EF770000F1770000000000008E
and fixes the problems I was having with the binary file made from the HEX file.
So... apparently the aforementioned project options in the IDE are used to create the scatter load file, and this absolutely located code from the default startup ASM file is not constrained by the scatter load file, and thus generates no errors or warnings, which would appear to be proper behavior.