Dear Community,
I am developing firmware for STM32l476VGT using Gnu Make Builder and "Ac6 STM32 MCU GCC" Toolchain. I encounter a memory related run time error during the startup (before main) of my controller. The error occurs during the execution of the LoopFillZeroBss section:
LoopFillZerobss: ldr r3, = _ebss cmp r2, r3 bcc FillZerobss /* Call the clock system intitialization function.*/ bl SystemInit /* Call static constructors */ bl __libc_init_array /* Call the application's entry point.*/ bl main LoopForever: b LoopForever .size Reset_Handler, .-Reset_Handler /** * @brief This is the code that gets called when the processor receives an * unexpected interrupt. This simply enters an infinite loop, preserving * the system state for examination by a debugger. * * @param None * @retval : None */ .section .text.Default_Handler,"ax",%progbits Default_Handler: Infinite_Loop: b Infinite_Loop .size Default_Handler, .-Default_Handler
After the execution of bl __libc_init_array I end up in the Infinite_Loop of the Default_Handler. It is worth noting, that this error can be influenced by the amount memory which is statically allocated. In my source code file there is an array
static uint8_t array[SIZE] = {0};
If SIZE is smaller than threshold1, I can enter main() without any problems. If SIZE is between threshold1 and threshold2 (with threshold1 < threshold2) then the behaviour is as described above. If SIZE exceeds threshold2, a linker error (section '.bss' will not fit in region 'RAM') is generated (as expected).
I have the following questions:
1. What exactly happens, when 'bl __libc_init_array' is executed?
2. How could the fail of this command possibly related to the memory usage?
Any thoughts or helpful sources on this topic would be greatly appreciated as well.
Kind regards
Oliver
One more little thing: I switched to the official ARM GCC toolchains a while ago because sometimes the ones maintained by the Chipmakers aren't up to date and so, when you have some extra time (just for the future) I'd suggest you migrate to the 7-2018-q2update...
Hey Sebastian,
thanks for your advice. I found out, that the error is difficult to reproduce. It didn't occur anymore until today, when I switched to another hardware sample. Now, with the new hardware I obtain a similar error as described above. The only difference is that I am now unable to get to the main function, no matter how severely I reduce my memory usage.
I cannot access the source code of __libc_init_array() since we are currently using this toolchain
https://www.st.com/en/development-tools/sw4stm32.html
and I can only access the libc.a file. Some progress on my side:
1. The flag
-falign-functions=4
didn't fix the problem.
2. Setting the compiler optimization level from -O3 down to -O2 seems to be a workaround for my problem.
I still have some questions:
1. Do you have an explanation or an educated guess why this workaround works?
2. Do you think changing to the official ARM GCC toolchain might fix this issue, since there might be a unresolved bug in the libs that we are currently using?
Best,
Hey Oliver,
sorry for the late reply, somehow I didn't see your message until now...
First of all: the STM Toolchain uses gcc, too so your __libc_init_array source is the one I posted earlier.If you step through the disassembly you'll see. Now, regarding the align-functions flag - did you also change the alignment from 8 to 4 here?
.init_array : { . = ALIGN(8);
Also, when your code works with -O2 it could be an option to try and narrow things down by adding the single flags from O3 one by one and see which one breaks it. You can find the gcc flags for each level here: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
I'd also try and step through the startup code in disassembly view (`lay asm`) with single instruction steps (`si`) and see where it breaks/hangs...
Last not least, when it comes to toolchains, the only real option to be on the safe side (and I hate to be saying this) is to buy a compiler that comes with some "warranty" and support (like IAR or Keil). As long as you're working with gcc you'll find yourself in situations like this every now and then again.But on the positive side, You learn a lot this way - believe me, been there done that ;)Sorry I can't be of more help right now - but it's really difficult to remote-diagnose such things.
Sebastian