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 06:29 AM
Use STM32CubeProgrammer to verify the contents of the flash. If they match, the error is in your program and not the bootloader. Otherwise, the bug is in your program. You can step through to see where it goes wrong, possibly the stack is overwritten, or a memory allocation fails.
2021-09-11 06:29 AM
Use STM32CubeProgrammer to verify the contents of the flash. If they match, the error is in your program and not the bootloader. Otherwise, the bug is in your program. You can step through to see where it goes wrong, possibly the stack is overwritten, or a memory allocation fails.
2021-09-11 06:36 AM
It spans a flash sector boundary, perhaps you don't erase or write correctly
4x 16KB (@ 0x08000000)
1x 64KB (@ 0x08010000)
7x 128KB (@ 0x08020000)
2021-09-11 11:42 AM
I have verified that flash is correct, currently I dont use bootloader to load the application it is loaded with keil to 0x08004000 up to 0x0801005D0. Could this be some kind of issue when the app goes to 0x08010000?
I cant step through the program, because it does not jump to the start of it, when I remove some C files it jusmps to HAL_Init as it should, I will try to remove different C files, and maybe will try to confirm if its application size or those C files are the issue.
2021-09-11 11:45 AM
Currently I dont use bootloader to load the application it is loaded with keil to 0x08004000 up to 0x0801005D0. So it should erase correctly. Also I have erased flash with STM32 Link utility and flashed bootloader and application, but if I try to debug application with Keil it does not hit the start of the application it jumps somewhere else. Could this be some kind of issue related that the application spans over 0x08010000 address?
2021-09-11 11:52 AM
My bootloader uses:
1 x 16KB (@ 0x08000000 - 0x08004000)
application uses all other
3 x 16KB (@ 0x08004000 - 0x08010000)
= 48KB
But now it is 50KB, which means it uses 2KB from
1 x 64KB (@ 0x08010000 - 0x080105D0)
Could it be that it cant handle next bigger sector 64KB when the application size becomes 50KB? Or maybe I need to set something for this sector or something?
2021-09-11 11:59 AM
Keil should be able to build and program.
Perhaps the BKPT comes from the use of a printf or STDIO functionality. If using the version 5 compiler, perhaps disable the semi-hosting and provide IO routines.
2021-09-11 12:26 PM
Indeed, it seems that the issue is in this line:
void CheckBytes(uint16_t bytesToCheck)
{
uint16_t bytes = MIN(64, bytesToCheck);
uint8_t buffer[bytes];
//...
}
My heap is set to 0. Does dynamic array allocation in function uses heap instead of stack? I thought it uses stack?
Still I would expect application crash once it hits this code? But it should not execute it on application start.
2021-09-11 12:32 PM
I have changed this code:
void CheckBytes(uint16_t bytesToCheck)
{
uint16_t bytes = MIN(64, bytesToCheck);
uint8_t buffer[bytes];
//...
}
To this:
void CheckBytes(uint16_t bytesToCheck)
{
uint16_t bytes = MIN(64, bytesToCheck);
uint8_t buffer[64];
//...
}
And now application runs without issue. So it seems it had issue with dynamic array creation. But this code should not run on the start off the application. why it crashes on the start? Does this code requires heap memory?
2021-09-11 12:57 PM
The stack and heap sizes are described in startup.s
That would use stack space.
In the C++ case, the constructors, called prior to main(), and after SystemInit() would need dynamic memory off the heap.