The NOLOAD section variable initializes with garbage value on hard reset.

[DVasa.1]

Hi ST team,

I want to define a new section in the ld script so I can use that for variables that have to keep their values in case of soft resets.

I have made some changes in the script as follows,

  .noinit (NOLOAD):

  {

  . = ALIGN(4);

    _noinit = .;

     

    *(.noinit .noinit.*) 

     

     . = ALIGN(4) ;

    _end_noinit = .;  

  } >RAM

I have also defined a variable of this kind in the following way,

uint32_t tempVar __attribute__ ((section(".noinit"))) = 0;

At every soft reset, the value of this variable is preserved. However, at every hard reset, the variable is initialized with some garbage value.

What am I missing here?

Thank you.

[Tesla DeLorean]

>>What am I missing here?

Ordering, what startup.s is actually doing, and the scope of the beginning/ending symbols in reality.

Watch also for where stack falls, or other code running, ie loader or system loader.

Content will be random at power-up.

[TDK]

What does a soft reset vs hard reset mean here? RAM won't be preserved on a power cycle.

[DVasa.1]

Hi Tesla DeLorean,

"Content will be random at power-up."

So, the content of that variable will be garbage at power-up, right?

Is there any way to prevent that from happening? Can we initialize it on power-up or something?

[DVasa.1]

Hi TDK,

What I mean by hard reset is the power cycle of the MCU. And by soft reset, I mean that giving reset pulse on the MCU using the reset switch.

[TDK]

You can write whatever value you want to it. But then it's not really NOLOAD any longer. If you need it to default to a value on powerup, NOLOAD is not what you want.

[TDK]

You can look at the RCC->CSR register to determine the source of the reset and handle them differently, if you want.

[DVasa.1]

Is it possible to initialize a variable on the power cycle, but preserve it on soft resets in RAM memory only?

Is there any other way than NOLOAD?

And regarding the RCC->CSR register;

We are using STM32l562CEU6. So in our case, there is no POR-related flag. But there is a BORRST flag. And default value of the VDD cut-off for BOR is 1.71V.

I kept a check of the previous reset condition using the RCC_FLAG_SFTRST and RCC_FLAG_BORRST with __HAL_RCC_GET_FLAG(__FLAG__) API. But If I give a pulse on the NRST pin of the MCU or power cycle the MCU, I can not differentiate using the flag check.

Am I missing something here?

[Tesla DeLorean]

>>Is it possible to initialize a variable on the power cycle, but preserve it on soft resets in RAM memory only? Is there any other way than NOLOAD?

Not via magic. NOLOAD means that the linker/startup code leave it alone..

You could use a signature and check over the content to determine if you want to keep the data or memset() it to zero.

What's the end-goal/purpose you're trying to achieve here? Any NV/BKP RAM in this part? Battery backup for RTC/BKP in design?

[DVasa.1]

What we want here is that a variable should be initialized with a specific value at every power cycle. At run time the value of the variable will be updated. But at every soft reset( i.e; pulse on NRST pin of the MCU), it should be preserved.

[TDK]

You'll need to use the RCC->CSR flags to get the functionality you want. The default startup scripts can not do this.

[DVasa.1]

We are using STM32l562CEU6. So in our case, there is no POR-related flag. But there is a BORRST flag. And default value of the VDD cut-off for BOR is 1.71V.

I kept a check of the previous reset condition using the RCC_FLAG_SFTRST and RCC_FLAG_BORRST with __HAL_RCC_GET_FLAG(__FLAG__) API. But If I give a pulse on the NRST pin of the MCU or power cycle the MCU, I can not differentiate using the flag check.

[TDK]

If you write to RAM, it'll stay there until you change it or it loses power. Many sections of RAM are initialized on startup and the NOLOAD is a way of skipping that initialization. You could do what NOLOAD does manually, or put the variable in a place in RAM which isn't touched or known about by the linker. However, if NOLOAD solves your problem, I don't know why you'd avoid using it.

[DVasa.1]

Using the RCC->CSR register flags, we were able to handle the scenario properly. What we were missing here was clearing the reset flags.

Thank you.