Posted on June 28, 2018 at 14:01The original post was too long to process during our migration. Please click on the attachment to read the original post.
>>I know that it's a long post but perhaps someone here would be able to help me.
Yes, it is a bit overwhelming. My approach would be to take the binary or hex file here, and disassemble and try and understand what the processor was being asked to do.
Not sure where the statics would get initialized, there is a copy, but nothing gets zeroed
I seem to think the F4 would need a 512-byte aligned VTOR.
Would expect 0x20001000 to be a vector table for the APP, not an address to jump too.
My preference is to get a USART/SWV channel working in the loader, along with a viable Hard Fault Handler. That way you could dump out data in RAM, and for the vectors and the transition.
Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
The problem was with proper alignment of the vector table. Firstly, it had to be aligned on a 512 byte boundary as you suggested. Secondly, I placed vector table at the start of the sections, before the code as you suggested. It caused some strange behaviour so I took a look at the disassembly of a .hex file. I discovered that even though .elf file showed that the locations of the code and the vector table were properly aligned in RAM, the locations in FLASH were not aligned. That caused the bootloader to wrongly copy data to RAM. It's described with more details
Regarding the statics initialisation. It's not neccessary for now (there are no static variables and globals) but it will be in the future. I wrote a function that initialises the bss and takes extern variables from linker scripts as an arguments but I have another problem there. I have the neccessary expressions in linker script:
.bss :
{ /* This is used by the startup in order to initialize the .bss secion */ /* define a global symbol at bss start */ PROVIDE(__bss_start__ = .); *(.bss) *(.bss*) *(COMMON) . = ALIGN(4); PROVIDE(__bss_end__ = .); /* define a global symbol at bss end */ } >RAMAPP
But when I look at the disassembly of an .elf file I can see that:
Disassembly of section .bss:
20001d88 <__bss_start__>:
20001d88: 00000000 andeq r0, r0, r0
20001d8c <object.6271>:
...
Disassembly of section ._user_heap_stack:
20001da4 <._user_heap_stack>:
...
So it properly 'creates' __bss_start__ variable but there is no __bss_end__.
When I try to use the __bss__end__ variable in the program, it's value is 0xffffffff. Do you know how to make sure that the variable in linker script will be created?
