i'm C++ developer for embedded systems, meaning microcontrollers, not embedded Linux. For example, currently i'm working with an STM32F7 and an STM32F4. On several occasions I stumbled over initialization issues, especially with the STM HAL and CubeMX generated code. Unfortunately, it's pretty hard to find good in depth information regarding the initialization procedure. Hence this post.

The problem:

Let's say for example I've got a class which implements some proprietary protocol (myProtocol) based on UART and my class hence needs a reference to the uart handle structure (hUart) that is generated by CubeMX. If the constructor of myProtocol accesses hUart, hUart might not be initialized already. This is because ST HAL and CubeMX are actually C and not C++. So CubeMX generates a call like MX_UART_Init and places it in main. As constructors of static objects are called before main, hUart won't be initialized for when a static instance of myProtocol is constructed.

My current Understanding:

The startup code, which is provided by STM, usually looks something like this:

Reset_Handler:  
  ldr   sp, =_estack      /* set stack pointer */
  
/* Call the clock system initialization function.*/
  bl  SystemInit   

/* Copy the data segment initializers from flash to SRAM */  
  ldr r0, =_sdata
  ldr r1, =_edata
  ldr r2, =_sidata
  movs r3, #0
  b LoopCopyDataInit

CopyDataInit:
  ldr r4, [r2, r3]
  str r4, [r0, r3]
  adds r3, r3, #4

LoopCopyDataInit:
  adds r4, r0, r3
  cmp r4, r1
  bcc CopyDataInit
  
/* Zero fill the bss segment. */
  ldr r2, =_sbss
  ldr r4, =_ebss
  movs r3, #0
  b LoopFillZerobss

FillZerobss:
  str  r3, [r2]
  adds r2, r2, #4

LoopFillZerobss:
  cmp r2, r4
  bcc FillZerobss

/* Call static constructors */
    bl __libc_init_array
/* Call the application's entry point.*/
  bl  main
  bx  lr    
.size  Reset_Handler, .-Reset_Handler

SystemInit: Usually does very basic stuff like setting the Vector table and configuring FPU.

LoopCopyDataInit: Initializes stuff like static struct instances which are not initialized to 0. Meaning it copies the init values from flash to the correct position in RAM.

LoopFillZerobss: All zero initializations like an array or a struct that is zero initialized.

__libc_init_array: Iterates through an array of constructors of static objects, which is generated by the compiler. Furthermore at least with GCC attribute((constructor)) can be used to explicitly add a C function to this list.

So finally my questions:

• Is my general understanding right?
• Could the issue be solved by simply adding a line like bl init_hardware to the startup code right bevor __libc_init_array and placing all the MX_Init functions in init_hardware to assure they are called before any constructor?
• Alternatively could the call to __libc_init_array be moved to main in order to reduce the deviation from CubeMX generated code?
• What would be your suggestions to handle this issue?

As I'm sure someone is going to post the following ideas, these are not what at least I am looking for:

• Don't access something like hUart within constructors.
• Lazy initialization using a base class that calls initialization code once in it's constructor.
• Using new or placement new to create the objects later, after the initialization of hardware is assured.

i'm C++ developer for embedded systems, meaning microcontrollers, not embedded Linux. For example, currently i'm working with an STM32F7 and an STM32F4. On several occasions I stumbled over initialization issues, especially with the STM HAL and CubeMX generated code. Unfortunately, it's pretty hard to find good in depth information regarding the initialization procedure. Hence this post.

The problem:

Let's say for example I've got a class which implements some proprietary protocol (myProtocol) based on UART and my class hence needs a reference to the uart handle structure (hUart) that is generated by CubeMX. If the constructor of myProtocol accesses hUart, hUart might not be initialized already. This is because ST HAL and CubeMX are actually C and not C++. So CubeMX generates a call like MX_UART_Init and places it in main. As constructors of static objects are called before main, hUart won't be initialized for when a static instance of myProtocol is constructed.

My current Understanding:

The startup code, which is provided by STM, usually looks something like this:

Reset_Handler:  
  ldr   sp, =_estack      /* set stack pointer */
  
/* Call the clock system initialization function.*/
  bl  SystemInit   

/* Copy the data segment initializers from flash to SRAM */  
  ldr r0, =_sdata
  ldr r1, =_edata
  ldr r2, =_sidata
  movs r3, #0
  b LoopCopyDataInit

CopyDataInit:
  ldr r4, [r2, r3]
  str r4, [r0, r3]
  adds r3, r3, #4

LoopCopyDataInit:
  adds r4, r0, r3
  cmp r4, r1
  bcc CopyDataInit
  
/* Zero fill the bss segment. */
  ldr r2, =_sbss
  ldr r4, =_ebss
  movs r3, #0
  b LoopFillZerobss

FillZerobss:
  str  r3, [r2]
  adds r2, r2, #4

LoopFillZerobss:
  cmp r2, r4
  bcc FillZerobss

/* Call static constructors */
    bl __libc_init_array
/* Call the application's entry point.*/
  bl  main
  bx  lr    
.size  Reset_Handler, .-Reset_Handler

SystemInit: Usually does very basic stuff like setting the Vector table and configuring FPU.

LoopCopyDataInit: Initializes stuff like static struct instances which are not initialized to 0. Meaning it copies the init values from flash to the correct position in RAM.

LoopFillZerobss: All zero initializations like an array or a struct that is zero initialized.

__libc_init_array: Iterates through an array of constructors of static objects, which is generated by the compiler. Furthermore at least with GCC attribute((constructor)) can be used to explicitly add a C function to this list.

So finally my questions:

• Is my general understanding right?
• Could the issue be solved by simply adding a line like bl init_hardware to the startup code right bevor __libc_init_array and placing all the MX_Init functions in init_hardware to assure they are called before any constructor?
• Alternatively could the call to __libc_init_array be moved to main in order to reduce the deviation from CubeMX generated code?
• What would be your suggestions to handle this issue?

As I'm sure someone is going to post the following ideas, these are not what at least I am looking for:

• Don't access something like hUart within constructors.
• Lazy initialization using a base class that calls initialization code once in it's constructor.
• Using new or placement new to create the objects later, after the initialization of hardware is assured.

• c++
• embedded
• microprocessors
• mcu

• 1 Solution is to not use any global/static variables at all. The real answer depends on C or C++ (so never tag them both). But dependency injection should work for both (and meyer's singleton may be an secondary choice for C++) – Pepijn Kramer Commented Apr 1 at 8:16
• 1 In other words, do not try to fix by modifying low level code, but by design. – Pepijn Kramer Commented Apr 1 at 8:22
• 1 @PepijnKramer "Solution is to not use any global/static variables at all" Oh so don't use any hardware peripherals of the microcontroller? That's helpful advice... – Lundin Commented Apr 1 at 8:49
• @Lundin Periphal addresses are global constants, not global variables. So I don't see an issue (they are not, or should not be, initialized from other variables either, so there should be no SIOF there). – Pepijn Kramer Commented Apr 1 at 9:39
• 2 @PepijnKramer They are pretty much identical to global variables in every meaning of the term. Naturally things like clock settings and baudrate register etc might be initialized from variables, but even without that, some serial bus peripheral initialization will rely on the system clock getting initialized in advance, and maybe on some DMA peripheral too. Plenty of potential for C++ fiascos in case drivers are implemented as classes, which is standard practice. This is in fact a common bug among those who still use C++ for MCUs. – Lundin Commented Apr 1 at 10:00

2 Answers 2

One way you could do it is to declare the object without initializing hardware dependencies in the constructor like

class myProtocol {
public:
    myProtocol() : hUart(nullptr) {} // instance, does NOT touch hUart in constructor
    
    // Initialize after hardware is ready
    void init(UART_HandleTypeDef& uart) {
        hUart = &uart;
    }

    void sendData(uint8_t* data, size_t len) {
        if (!hUart) return; // Safety check

        ....
    }

private:
    UART_HandleTypeDef* hUart;
};

myProtocol protocol; // Global/static 

to explicitly initialize the object later with the init() method while hUart is ready.

Is my general understanding right?

Yes, what you posted is a very typical "C runtime" (CRT). The "static initialization fiasco" in C++ is related both to .data and .bss initialization as well as default constructors.

However, the rules for initialization in modern C++ are non-trivial, so what guarantees the language makes depends a lot on C++ version. The CRT code you posted looks valid for pre C++11 but not necessarily so for post C++11.

Could the issue be solved by simply adding a line like bl init_hardware to the startup code right bevor __libc_init_array and placing all the MX_Init functions in init_hardware to assure they are called before any constructor?

Yes, no, maybe? It depends on what all constructors in your program do and what hardware requirements you've got. If it is critical stuff like setting watchdog, clock or GPIO registers, then you could indeed consider tweaking the CRT - more info about how to do that proper here.

What would be your suggestions to handle this issue?

For non-critical constructors, simply do not put code which might rely on static initialization order inside constructors, but instead create an explicit "init" member function which you can call at an appropriate time.

The problem isn't just the initialization order fiasco, but also that default constructors are hogging a lot of start-up time of the MCU, at a time when more important code needs to run or in case you simply wish the program to start in a timely manner. This is a big language design problem with the C++ language itself, making it unsuitable for microcontrollers.

For example, a very typical error handling implementation in microcontrollers goes like this:

• A critical error was found and it may be related to hardware register settings.
• Starting over from main() is therefore not sufficient, we have to force a MCU reset (through the watchdog etc) so that all registers return to default values.
• When we come out of reset in a timely fashion we can immediately (by slow human standards) check if the error persists or if it is gone.

The C++ language makes such sensible error handling problematic due to "default constructor lag". This alone is reason enough to port to C (if implementing the register map with conventional union type punning wasn't already).