Platform configuration lost between _start and main

Question

I am using https://github.com/ARM-software/CMSIS_5/blob/develop/Device/ARM/ARMCM33/Source/startup_ARMCM33.c file with following modifications:

_NO_RETURN void Reset_Handler(void)
{
  __set_MSPLIM((uint32_t)(&__STACK_LIMIT));

  SystemInit();                             /* CMSIS System Initialization */
  lpuart_init(&m33_uart, (void*)LPUART0_BASE, LPUART); // Initialize LPUART
  __PROGRAM_START();                        /* Enter PreMain (C library entry point) */
}

The __PROGRAM_START(); will jump to _start which will do all the runtime configurations mentioned in the crt0.o and then it will jump to main (See https://embeddedartistry.com/blog/2019/04/08/a-general-overview-of-what-happens-before-main/ for more details).

In above snippet, I am doing LPUART initialization before _start. After debugging the .elf, I got to know that this LPUART initialization gets lost when program reaches to main. Surprisingly, the same program works if I do LPUART initialization inside main:

void main() {
lpuart_init(&m33_uart, (void*)LPUART0_BASE, LPUART);

/* some more code 
...... */
}

It seems crt0.o is doing something that will cause loss of the LPUART (or platform) configuration. I am not able to figure out the reason. Any help?

Edits:

void lpuart_init(lpuart_info_t* p_info, void* base_addr, uint32_t version)
{
    p_info->base_addr = base_addr;
    p_info->version = version;
}

Answer 1

Global variables are initialized after your function is executed. So any modification to variables that are in .data and .bss segments will be lost and overwritten by the static initialization routine.

Drop the method you are doing and use the gcc non-portable extension __attribute__((__constructor__)) to execute a function before main but after static initialization or alternatively add the address of the function to the .init section. Links newlib/arm/crt0.S gcc function attributes newlib/init.c gcc initialization

A pseudocode example to illustrate what is going on:

int some_global_explicitly_initialized_var = 1; // in .data section
static int some_global_var = 2; // in .data section
int global_vars_without_initialization_are_default_initialized_to_zero; // in .bss section
static int m33_uart; // in .bss section

int your_func() {
   // you set your variables, but it will be overwritten in _init
   m33_uart = 12354;
}

// this function is called first, ie. entrypoint before main
void Reset_Handler(void) {
    your_func();
    _init();
}

void _init(void) {
    // variables in .data section are initialized explicitly
    // ie. some_global_explicitly_initialized_var is set to 1 and 
    // and some_global_var is set to 2
    // this is done by copying a section from flash memory into ram into .data section
    // linker takes care of properly placing the variables
    memcpy(&_data_section, &_data_initialization_from_flash, sizeof(_data_initialization_from_flash));

    // variables in .bss section are initialized to 0
    // and uninitialized pointers are set to NULL
    // so all global variables are cleared
    // so global_vars_without_initialization_are_default_initialized_to_zero is set to 0
    // and m33_uart is also set to 0
    memset(&_bss_section, 0, sizeof(_bss_section));

    // after that main is called
    main();
}

int main() {
    // m33_uart will be set to 0
    // because m33_uart is inside .bss section
    // and will be cleared to 0 by the memset in _init
}

By the term "static variables" in my comments I meant variables with static storage duration (not with internal linkage that is what static keyword does, sorry for confusion if any). Note about initialization of variables with static storage duration - they are zero initialized.

Answer 2

It isn't always safe to call C functions from the reset vector, in case the reset vector also sets the SP. Fortunately this is not an issue with ARM, but you must still ensure that all memory setups are done before you write to RAM variables (some advise for how to roll out all of this manually here). As mentioned by others, the most likely issue here is that you write to static file scope variables before .bss initialization has been done, so their values will get erased.

(If you have no clue what .bss and .data means, then you shouldn't be meddling with the CRT for now. Here's an explanation: What resides in the different memory types of a microcontroller?)

There are two feasible solutions:

• Disable .bss and .data initialization as a non-standard project setup. This is very common in embedded systems, but means that you can no longer rely on standard C variable initialization of static or file scope variables.
• Or place your internal UART driver variables in a dedicated RAM segment, which is not default initialized.

The real question is why you need to setup UART so early though. UART registers cannot be that time critical, since UART itself is slow. It should be sufficient if you set data direction and pull resistors from the reset vector, then do the rest of the non-critical initialization in main().

Also, it makes little sense to initialize UART before you have set the system clock, or your baudrate might end up wrong. On that topic, it is also quite possible that the CRT/CMSIS libs were written by monkeys who seriously intend to run your .bss/.data initialization on the default internal RC oscillator setting, before any system clock of PLL setup has executed. Since most boards use external quarts, you don't want your startup to be incredibly slow and needlessly current consuming for no reason - to prevent such horrid design, you need to either setup the clock yourself from the reset vector, or disable .bss/.data initialization.