Hi there,
I'm working on a bootloader that uses a hex file.
What does this row do?
:0400000508000131BD
It breaks up to these:
: Start code 04 Byte count: 4 0000 Address 05 Record type: Start Linear Address Record 08000131 <--- is this a start address? BD Checksum
Does it say the execution start (IP) address is 0x08000131? My main program range is from 0x08000000 to 0x0800261. Or should I discard the line altogether?
Thanks. -Mad D
I changed the start locations to check whether thats what you meant...
What I really meant is that the starting address doesn't necessarily follow the vector table. It is possible to reorder sections more or less arbitrarily, so the starting address may end up in the middle of the firmware code. But that doesn't have anything to do with bootloader.
What I am thinking is to have the bootloader in the lower address and then jump to the program in the :0400000508010131BC record. What do you think?
That makes sense. Don't forget to adjust the vector table offset register of the NVIC in your main application since the vector table will not be at its usual location. Still, I think it's better not to rely on the start address record in the HEX file. The start address record can be lost if you convert the HEX file (say, hex->bin->hex, or whatever.) Fetch the starting address from 0x08010004 and use it instead.
Hello Mike,
Thank you for the very informative replies. I found what you were talking about earlier, I'm just going to post it in case someone else reads this.
Quoted from the manual: After this startup delay has elapsed, the CPU fetches the top-of-stack value from address 0x0000 0000, then starts code execution from the boot memory starting from 0x0000 0004. ...the Flash memory contents can be accessed starting from address 0x0000 0000 or 0x800 0000.
0x00000000 05D0 LSLS r0,r2,#23 0x00000002 2000 MOVS r0,#0x00 0x00000004 0145 LSLS r5,r0,#5 0x00000006 0800 LSRS r0,r0,#0
0x08000000 05D0 LSLS r0,r2,#23 0x08000002 2000 MOVS r0,#0x00 0x08000004 0145 LSLS r5,r0,#5 0x08000006 0800 LSRS r0,r0,#0
Vector table for other STM32F10xxx devices
Description - Reserved Position - Priority - Type of priority - Acronym - Address - 0x0000_0000
Description - Reset Position - Priority - -3 Type of priority - Fixed Acronym - Reset Address - 0x0000_0004
Sorry, I had to break it into two posts...
I can see that the top-of-stack address is 0x200005D0 in the SRAM and the start address is 0x08000145, which is different from 0x08000131. Any idea why?
I have set the stack to 0x400 and heap to 0x400. Why is the top-of-stack 0x5D0?
Cheers.
-Mad D
The answer to both questions is "Why not?" Apparently, you have some expectations as to the resulting firmware image layout and the linker is not meeting your expectations. I have no idea where those expectations came from. They should come from the manual. You should familiarize yourself with the linking process. Read up on sections, regions, scatter files, etc:
http://www.keil.com/support/man/docs/armlink/