MSPM0G3507: How to allows a variable to be not zero-initialized at startup or reset

Thank you very much!
I followed your instructions:
       

and the variable in SRAM is only not reinitialized upon a level 0 reset  as described in the table: 

DL_SYSCTL_resetDevice(0);

-----------------------------------------------------------------------

However, when I perform a hardware reset or other reset levels, the variable still gets reinitialized. 

Did I do it correctly, or is there a way to prevent the variable  re-initializing with any reset (besides storing it in FLASH by DL function, as that consumes time and resources)?

Hi Goku,

From my perspective, if you ask the variable not initialzed, this means you want to maintain the data.

Son Goku said:

However, when I perform a hardware reset or other reset levels, the variable still gets reinitialized. 

It requires a certain value when you fisrt tun the application. Or it will be a random value, which is not meaningful for your application.

Maybe you can take a look into "c_int00" assembly code, I am not sure whether there is a method here to make it un-initialzed within BOR.

Son Goku said:

Did I do it correctly, or is there a way to prevent the variable  re-initializing with any reset

There does have 4bytes within MSPM0 device, which can maintained in BOR reset, which means it will not be initialized.

For POR reset, I do think there any way to keep the varible maintained except the FLASH.

B.R.

Sal

Thank you very much Sal,
In my project, I need a variable called 'volume_counter' to be continuously assigned the measured value from a sensor every second (for example, water usage).

I cannot keep erasing and writing to FLASH and then reading it repeatedly for this variable because it is time-consuming and the number of FLASH write cycles is limited 1000000 times. Even worse, if the MCU resets before I can write to FLASH, the measurement could become inaccurate.

Do you have any recommendations for the most suitable solution for this project?

Thank you very much!

Hi Goku,

Considering the POR reset, it requires a EEPROM solution here.

It can maintain the data, and even if the reset happen in the FLASH writing, there will be maintain the last writing value as the correct one.

You can find the implement demo project in SDK, and we provide the documents in the TI.com.

Son Goku said:

it is time-consuming

Writing flash is quick. Only concern is the erase operation when manage the flash address. 

Son Goku said:

the number of FLASH write cycles is limited 1000000 times.

When use EEPROM, the equivalent endurance will be increased to 1M times, or even higher (use more flash memory will increase it).

B.R.

Sal

Have a nice day Sal!
I will try to save the variable using the EEPROM emulation type B design next.
I will also continue to study the documentation more carefully and believe I can find a suitable solution.
However, I still have two final concerns:

1. When SRAM always has power (via a pin), it should behave almost like non-volatile memory. So why can't maintain the last value after a reset? The MSP430FR can do this (I have already tested saving a variable in the RAM in an OTA project). Is that correct?

2. Another MCU, the STM32L151C8T, has a similar memory architecture but can easily achieve this by slightly modifying the SRAM configuration in the linker.

   Do you have any thoughts on these two issues?"

Have a nice day Sal,

Hi Son,

Son Goku said:

if it is automatically executed by hardware upon detecting a change in a specific bit?

No, it is hardware controlled. And I suppose this will be closed only in the VDD lost, or entry shuntdown mode.

From my perspective, manually trigger POR/BOR usually will not reset Vcore, Vcore will be maintain exclude the VDD loss.

B.R.

Sal

Hi Son,

Yes, I agree with you. I miss this information in TRM.

While, only one things is that, the Vcore might not power cycles, only the PMU module is power cycled.

And yes, all SRAM content will not maintianed due to this.

B.R.

Sal

Thank you very much Sal,

Sal Ye said:

While, only one things is that, the Vcore might not power cycles, only the PMU module is power cycled.

I will review the TRM documentation again and base on the table provided to determine the most suitable method for the project!

Thank you very much for your assistance in this topic for me!!

Best Regards.

Son

Hi Son,

Thanks for feedback. I will close the thread, and feel free to file a new one if there has further questions.

B.R.

Sal