RAM state after power on reset

[joel-sc]

Hello,

I'm facing an issue with the behavior of the RAM state in the NRF52840 after a brownout reset.

Context: I've implemented a simple bootloop detection where a boot counter is incremented at the very beginning of each boot and cleared to 0 once our firmware initialization is over. During increment, the counter is checked against a maximal value, and if the counter reaches this maximal value, the firmware resets into the bootloader and waits for DFU. This allows a safety mode if the device is bricked and cannot boot properly. The boot counter is stored in a noinit region. This region is mapped in memory so that the reset handler won't reset it.
There are two ways to reset this counter:

 1. Terminate the booting/initialization stage properly.
 2. Have a full power on reset, as that will clear the RAM.

The problem I'm facing is that sometimes we have short power failures in our system, and this seems to disrupt the behavior of the anti-brick system. I have observed that if the power failure is too short in time, the boot counter is not reset to 0 but kept to the the last value.

The MCU's Vdd is 1.8V. I've made some measurements where I can observe the issue.

In this measurement, we can see that the duration of the power outage is about 12.3 ms. Vdd starts at 1.8V, then drops to 800 mV, and then goes back to 1.8V.

Best
joël

[ovrebekk]

Hi Joël

I am not quite sure I understand the problem. 

If a power failure is causing a brownout reset, then it is hard to say how that will impact the status of the RAM. 

If the boot counter is not reset, but kept to the last value, wouldn't that allow the anti-brick system to continue? 

Are you worried that you will get false positives, where the anti-brick system will boot into the bootloader even if the firmware is technically functional?

I assume the power failure must happen during the boot sequence for this to be a problem?

Best regards
Torbjørn

[joel-sc]

Hi!

Let me show you the pseudo code of the idea.

// NOINIT object won't be reinitialized during the reset handler
#define NOINIT __attribute__((section(".noinit"))) volatile

static NOINIT boot_counter = 0;
int main() {

 	boot_counter++; 
	if (boot_counter > 15) {
		// clear the boot counter
		boot_counter = 0;

		// prepare to enter into the dfu
		do_some_stuf();

		// jump into the bootloader and wait for dfu
		nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_DFU);
	}

	// bsp, peripheral, BLE initialization...
	fw_init();

	// From now the firmware is available by BLE, it is considered as safe and reachabl

	// clear the boot counter
	boot_counter = 0;

	// application running forever
	app_run();
}

The idea is to protect the boot and initialization sequence until the boot counter is cleared. With this code, there are three ways to clear the boot counter:

1. The boot counter has reached the maximum (15) and is cleared before going into the bootloader from the application.
2. fw_init() has passed, and the device is available by BLE and considered reachable by BLE.
3. Power off and on the device.

During the design process, I assumed that sufficient power loss that causes a brownout reset would clear the content of the memory, and thus the boot counter would be 0 at boot. Now I am facing this issue I am not sure about this assumption anymore. My main problem is not the behavior of the anti-brick system, but the validity of the RAM state after a power up if there is a short power outage (a few milliseconds in my last measurement). The anti-brick system just exposed the issue. To fix this, I could simply clear the boot counter if the reset cause is coming from a brownout, but that is not my question.

My questions are:

• How is the RAM initialized after power on or reset (before going into the reset handler)?
• What is the state of the RAM after reset, and is it specified?
• What is the state of the RAM after power off and on, and is it specified?
• Is there any timing constraint for clearing the RAM content after power loss?

Thank you for your time!

Joël

[ovrebekk]

Hi Joël

The RAM state is unspecified at boot unfortunately. This is why by default all used RAM will be explicitly zero initialized during boot (except for noinit RAM, or data RAM that must be assigned some value other than 0). 

A reset doesn't reset the RAM either, but the content might be corrupted because of power loss. The reset behavior table has a bit more information about this. 

The only resets that should leave the RAM alone is CPU lockup reset and soft reset, as shown in the table. 

Like you indicate I think you will need to use the RESETREAS register to figure out what was the cause of the last reset, and set the boot counter accordingly. I am assuming the reset reason in the cause of a lockup would be either CPU lockup or soft reset. 

Hopefully that answered all your questions?  
If not please let me know, and I will get back to you. 

Best regards
Torbjørn

[joel-sc]

Hello Ovrebekk

ovrebekk said:

The RAM state is unspecified at boot unfortunately. This is why by default all used RAM will be explicitly zero initialized during boot (except for noinit RAM, or data RAM that must be assigned some value other than 0). 

Okay but I'm wondering more about the RAM peripheral itself, like I assume that the RAM peripheral is not composed only by cells but also by logic gate, memory controller, adc maybe... I don't know.

Anyway, maybe I could rephrase  and generalize my question:

Is there any specification regarding the power down an up sequence in term of voltage and timing ?
Can I assume that at the beginning of the reset handler, the whole CPU is in a sane and valid state, this is true _every_ time ?

ovrebekk said:

Like you indicate I think you will need to use the RESETREAS register to figure out what was the cause of the last reset, and set the boot counter accordingly. I am assuming the reset reason in the cause of a lockup would be either CPU lockup or soft reset

Thank you, I'm indeed already using this to know the reset reason at boot.

Thank you very much for your time

Joël

[ovrebekk]

Hi Joël

joel-sc said:

Okay but I'm wondering more about the RAM peripheral itself, like I assume that the RAM peripheral is not composed only by cells but also by logic gate, memory controller, adc maybe... I don't know.

The various support circuitry will be in a know state after a reset, yes, such as the ABH bus and memory controllers. Just not the memory content itself. I am not a hardware designer, but I assume that designing a RAM that could be fully reset would increase either the cost or the power consumption, or both. 

joel-sc said:

Is there any specification regarding the power down an up sequence in term of voltage and timing ?

Not really. The power on reset functionality ensures that the device is not powered up until a stable supply is available. 

We do have some specifications regarding how the rise time of the supply affects the device startup time, which you can find here. Essentially a slow rise on VDD will increase the time the device is kept in reset by the power on reset circuitry. 

joel-sc said:

Can I assume that at the beginning of the reset handler, the whole CPU is in a sane and valid state, this is true _every_ time ?

Yes. This is the responsibility of the power on reset functionality, and the overall reset feature of the various peripherals and system blocks, to make sure that your device doesn't start until it has a stable supply, and that all peripherals are reset to a known state when the CPU starts running. 

Best regards
Torbjørn

[joel-sc]

Hi Torbjørn

Thank you! I think you have answered my questions.

I'll then consider my "noinit" region invalid if the reset cause is either cpu lock up or soft reset-

EDIT: I'll consider the noinit region only valid if the reset is coming from a soft reset or cpu lockup.

I wish you a good day!

Joël

[ovrebekk]

Hi Joël

joel-sc said:

I'll then consider my "noinit" region invalid if the reset cause is either cpu lock up or soft reset-

Maybe it's too late on a Friday and my mind is drifting, but shouldn't your region be invalid unless the reset cause is CPU lock up or soft reset? 

A good day and a great weekend to you too

Best regards
Torbjørn

[joel-sc]

Oops, I apologize for the confusion. I mixed up my words when posting.

[ovrebekk]

No worries, good to know we are on the same page