2021-09-11 03:43 AM
Hi, I have STM32F407VET6 with a bootloader which reads microSD card, checks for user application update, flashes if it exist and jumps to use application 0x08004000.
All was working fine when my user application was <48kb. I wrote some additional code (which should not impact the start of the application), and now id does not work.
Previously debbugging started at "HAL_Init()" like it should when user application was <48kb
But now, when user application is >50kb it starts debugging at some kind of wrong address:
It does not hit "HAL_Init()" anymore like it should.
Why user application size could impact that? Or it could be some kind of different issue?
How could I fix this?
Solved! Go to Solution.
2021-09-11 01:09 PM
I always set heap to 0 since I dont use it, but seems that dynamic arrays need it.
2021-09-11 01:44 PM
Constructors don't use heap space unless you're dynamically allocating them with new/malloc or things within them, which would be an odd choice if they're globally defined.
Can't see why the posted code would need heap. I compiled it with GCC and it's using the stack there.
When you debug, you can start at Reset_Handler, which is the very first thing executed after reset. If it winds up in HAL_Init, some code is causing it to move there. main() is eventually called, but that's not where it starts. In CudeIDE, there is a startup_*.s file. I imagine there is something similar in Keil.
2021-09-11 02:06 PM
In the 1st case you use the C99 feature: allocation of variable size array (VLA) on stack.
Probably the compiler or runtime library does not quite support this.