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 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 tried different HEX2BIN utilities and they all made identical BIN files, so I looked closer at the HEX file made via uVision. I discovered a few lines at the top and bottom of the HEX file that seemed like they didn't belong. So, I cut them out and that got rid of all the leading 0xFF chars, which resulted in a BIN file that was almost what I wanted. It was then just missing the leading 4 0xFF's that are used to load the SP on startup. So I added one line to the top of the HEX file and then the different HEX2BIN utilities made identical BIN files that [were what I expected, and] worked for me.
These are the lines I cut from the top of the HEX file:
:020000040000FA :0402FC00FFFFFFFF02 :020000040000FA
These are the lines I cut from [almost] the bottom:
:04B8B000040144004B :04000005000020CD0A
I left this line at the bottom:
:00000001FF
This is the line I inserted into the top:
:041FFC00FFFFFFFFE5
It'll be an easy thing to create a HEX file post-processor to fix this problem (so my build process can remain fully automated), but I can't figure out why I had to edit the HEX file to get what I thought it should've started out as. If I'm using the linker target options and specifying the starting address of MCU flash ROM as 0x2000, why does the HEX file contain such a large section of 0xFF's (from 0 to 0x1D00) before the start address? Creating a BIN file from this (malformed?) HEX file results in an unusable BIN file that does not represent what I think was configured via the uVision IDE.
Can anyone shed any light on this conundrum?
Thanks, Dave
There's an Intel HEX file statistics utility (github.com/.../Intel-HEX-Class) that I ran on the original (app.hex) and edited (app2.hex) HEX files, and this is what it outputs:
>ihstat app.hex Statistic for file: C:\code\project\app.hex Start address: 0x000002FC End address : 0x0000B8B3 Address range: 46520 bytes Data bytes : 39096 Finding empty regions... Between 0x00000300 and 0x00001FFF are 7424 free bytes. >ihstat app2.hex Statistic for file: C:\code\project\app2.hex Start address: 0x00002000 End address : 0x0000B8AF Address range: 39088 bytes Data bytes : 39088 Finding empty regions... ...no empty regions in file.
Note that the unmodified HEX file created by the uVision build process has a huge blank section prior to where the app is supposed to start. Why does uVision put this huge block of blank space before the start of the app?
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.