Hi,
I wrote a program using the SES + STM32 platform, which has been running well and has been applied to over a million products, but recently I found that there are occasional hardfault cases. After analyzing the stack data and the corresponding assembler code, it was found that the value of a variable was unexpectedly changed to a particularly large value. This is a static local variables within the function, I checked the code, feel code should not lead to this problem, I also analyzed the map file, find the address of the variable, in the front of the RAM, the system stack at the end of the RAM, so should not because the reason of stack overflow, also because the stack is large enough (8 KB in size), and between the variables and stack separated by about 4 KB address, if the stack overflow, so should be in before they lead to hardfault affects this variable. Then I also looked at whether the variable's adjacent address (especially its previous address) had some pointer manipulation that might cause it to be tampered with, and found no such pitfalls. The only thing I can think of right now is, in order to save code space, I'm going to use optimize for size. I know I shouldn't doubt the compiler, but there's no other explanation.
Then I'm ready to debug it, and it turns out that sometimes when the program runs to the main function, the value of this variable is already a large value (it should be 0), but it's amazing that even then, sometimes the program can continue to run, but sometimes it goes straight to hardfault. So I set a conditional breakpoint, when writing the variables corresponding to the RAM address into the breakpoints, and then I found is in thrumb_crt0.s file Settings. The BSS into breakpoints, and then I switch to the assembly instruction window one step to run the program, and then discovered a strange phenomenon in particular, when I perform to a STRB r2, (r0) instruction, RAM data of unexpected changes have taken place. I tried it over and over and over and over again. I took screen pictures from debugging and videotaped them, and I uploaded them. I don't know how this happens, but after using compiler optimization, the result of debug is no longer trusted?
I wrote a program using the SES + STM32 platform, which has been running well and has been applied to over a million products, but recently I found that there are occasional hardfault cases. After analyzing the stack data and the corresponding assembler code, it was found that the value of a variable was unexpectedly changed to a particularly large value. This is a static local variables within the function, I checked the code, feel code should not lead to this problem, I also analyzed the map file, find the address of the variable, in the front of the RAM, the system stack at the end of the RAM, so should not because the reason of stack overflow, also because the stack is large enough (8 KB in size), and between the variables and stack separated by about 4 KB address, if the stack overflow, so should be in before they lead to hardfault affects this variable. Then I also looked at whether the variable's adjacent address (especially its previous address) had some pointer manipulation that might cause it to be tampered with, and found no such pitfalls. The only thing I can think of right now is, in order to save code space, I'm going to use optimize for size. I know I shouldn't doubt the compiler, but there's no other explanation.
Then I'm ready to debug it, and it turns out that sometimes when the program runs to the main function, the value of this variable is already a large value (it should be 0), but it's amazing that even then, sometimes the program can continue to run, but sometimes it goes straight to hardfault. So I set a conditional breakpoint, when writing the variables corresponding to the RAM address into the breakpoints, and then I found is in thrumb_crt0.s file Settings. The BSS into breakpoints, and then I switch to the assembly instruction window one step to run the program, and then discovered a strange phenomenon in particular, when I perform to a STRB r2, (r0) instruction, RAM data of unexpected changes have taken place. I tried it over and over and over and over again. I took screen pictures from debugging and videotaped them, and I uploaded them. I don't know how this happens, but after using compiler optimization, the result of debug is no longer trusted?