This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Memory related issue with MCU startup ( __libc_init_array )

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

Parents
  • Greetings,

    I encountered this issue this week and found this topic as similar.

    I bet that your __init_array has a proper size (2 words as function pointers), but second is 0x0 because __init_array_start is somehow shifted !! Im currently tackling this problem and I found that my first element in __init_array_start is just 1 word above from where it should be. Seems like a compiler issue because __init_array_start and __init_array_end are both 1 word shifted, which results in a correct size calculation within Reset_Handler() but leading to a call of the last element which is indeed empty. 

    In my case, i had to change my startup code to iterate from __init_array_start[-1] to __init_array_start[count - 2] but unfortunately, this shift is related to a code payload (i.e number of chars in debug messages, because they are padding final image size).

    Any news after this thread has started?

    Best, 

    Ernest

Reply
  • Greetings,

    I encountered this issue this week and found this topic as similar.

    I bet that your __init_array has a proper size (2 words as function pointers), but second is 0x0 because __init_array_start is somehow shifted !! Im currently tackling this problem and I found that my first element in __init_array_start is just 1 word above from where it should be. Seems like a compiler issue because __init_array_start and __init_array_end are both 1 word shifted, which results in a correct size calculation within Reset_Handler() but leading to a call of the last element which is indeed empty. 

    In my case, i had to change my startup code to iterate from __init_array_start[-1] to __init_array_start[count - 2] but unfortunately, this shift is related to a code payload (i.e number of chars in debug messages, because they are padding final image size).

    Any news after this thread has started?

    Best, 

    Ernest

Children
No data