Hi,
im using a STM32F429ZI with CubeIDE 1.7.0 and firmware version 1.25.0 for my project. The project doesn't use an operationg system.
During coding, I worked with debug settings and without compiler optimizations and everything worked fine. When turning on compiler optimizations (-Os, -O3, -O2, doesn't matter), a hard fault occured during the initialization phase of the program, where I switch on various timers, IRQs, SPI busses and DMAs.
I started to investigate the problem and found some really strange behaviour: the push instruction at the entry of a function (HAL_TIM_RegisterCallbacks), pushing r4 and lr to the stack, failed. Lr was pushed correctly, but only the least significant byte of r4 was written to memory. The other three bytes contained the same value as before.
When I set a breakpoint right at the push instruction and then step debug the push, everything works fine. When I set a breakpoint at the instruction right after the push and inspect the memory at sp, only the least siginficant byte is set.
In order to investigate further, I added some inline assembler just before the function call pushing some registers to the stack and popping them back.
- Push 4 - Pop 4
- Push 5 - Pop 5
- Push 4 - Pop 4 - Push 5
- Push 4 - Push 5 - Pop 4 - Pop 5
- Push 4 - Push 5 - Pop 4 - Pop 5 at other stack position
- Push 2 - Push 5 - Pop 2 - Pop 5 at other stack position
To summarize:
Whenever I push to a specific, relative (to an unknown reference) stack position, only the least significant byte is written. This is independet on the number of push instructions needed to reach this stack position, the number of registers written with this instruction or the absolute stack position in memory.
Has anybody seen this behaviour before? Or does anybody have an idea, what could be the underlying problem here?
1 ACCEPTED SOLUTION
Accepted Solutions
When I tried this with the inline assembler code, the pop did in fact get the correct values from the stack, although the memory browser showed the wrong value.
I then removed the inline assembler code and reproduced the situation which threw the hard fault.
From main(), I call TaskInit() which in turn calls HAL_TIM_RegisterCallbacks. Both functions take a pointer to TIM_HandleTypeDef as parameter. In my case, this is htim7 at 0x20002374.
First, I stopped in TaskInit() right before the branch to HAL_TIM_RegisterCallback.
In the next turn, we stop just after the HAL_TIM_RegisterCallback() is branched to.
Again, next turn, stopping just after the HAL_TIM_RegisterCallback has popped the stacked values and returns to TaskInit().
If I would have stepped through the instructions after the first breakpoint, everything would have worked as expected. But if I restart the program and disable the previous breakpoint(s), this is the result.
