Getting Reset Reason as Watchdog Reset after image update

[Srinivas V]

Hi Team

We are using the Nrf52840 module for our dev purpose. As part of image update, we Erasing and load the new image to the chip by using Nrf connect App with Jlink Debugger.

After flashing is done, board is Reset and running, at that time when read the  below register, it is always showing reset reason as Watchdog Reset "DOG".

                                                                                           NRF_POWER->RESETREAS 

Without Image update when we power on reset the board, it is showing the Reset reason as  "-RESETPIN".

So when ever we update the image and run the board , by default the Reset reason it should  show "-DOG", is this is expected only, some issue is there is by default. Could anyone give clarity on this one.

Regards,

Srinivas.V

[Kenneth]

Remember that after reading the RESETREAS register you must clear it by writing '1' to all bits, since the RESETREAS register is retained and can store previous reset values if not cleared.

Kenneth

[Srinivas V]

Hi Kenneth,

Thanks for your reply. On main function at every start up, we are reading and clearing the Reset reason.

            nrf_power_resetreas_get();

            nrf_power_resetreas_clear(nrf_power_resetreas_get()); //NRF Clear after reset

Here our doubt is what is expected reset reason when we do the Flash Erase followed new image update with Nrf Connect with jLINK Debugger.

when we reset the board without flashing it is showing the Reset reason as  "-RESETPIN"., but when we erase and flash the board after that when we read the Reset reason showing the reset reason as Watchdog Reset "DOG".

Here why it is showing two different Reset reasons, can you please clarity on this one.

Regards,

Sinivas.V

[hmolesworth]

(Sorry if this reply doesn't align with last message)

Reset is not always what you expect; to be sure power-cycle and power on at least twice before looking at the reset reason to prove the scenarion you describe, as a single power cycle often generates a reset before you get to user code which looks at the reset reason and therefore shows the wrong reset reason. Alternatively place the code which captures the reset reason at the start of the following function, as this function often generates a reset (for example to apply reset pin programming) after a flash erase and reprogram. This function runs before main()

// User information configuration registers (UICR) are written in the same way as Flash. After UICR has been
// written, UICR registers that configure HW (offset 0x200 or higher), including REG0 & Reset pin, require
// a reset to take effect since UICR is only read during startup.
void SystemInit(void)
{
    blah-blah
    // UICR changes require a reset to be effective
    NVIC_SystemReset();
...
}

[Srinivas V]

HI Kenneth,

I got your point, some times after a flash erase and reprogram also generates a reset condition. As explained to take the effect of UICR registers also some times needs Reset.

But specifically getting the Reset Reason as "DOG" after flash erase or reprogramming is there any specific reason, like which is causing this one like UICR registers or some other source.

Could you please provide more clarity on this one.

Regards,

Srinivas.V

[Kenneth]

If you enable watchdog at any time, then you need to feed/reload the watchdog, else it will timeout and trigger watchdog. This is the case even if you reflash the chip, only way to stop watchdog is a hard reset (power cycle or pin reset).

Kenneth

[Srinivas V]

Hi Kenneth,

Thanks for giving support.

As per your explanation, we have enabled the watchdog and we are refeeding at the end of while loop every time.As part of reprogramming we are erasing and reflashing, it means while erasing the complete code in flash will erase the  watchdog configuration and register settings as well .So if that is the case, after reflashing we are enabling and refeeding. So where is the gap for watchdog to trigger the timeout event in between after flashing and code start the execution. Somewhere i am getting interest on this point.

Regards,

Srinivas.v

[Srinivas V]

Hi Kenneth,

Thanks for giving support.

As per your explanation, we have enabled the watchdog and we are refeeding at the end of while loop every time.As part of reprogramming we are erasing and reflashing, it means while erasing the complete code in flash will erase the  watchdog configuration and register settings as well .So if that is the case, after reflashing we are enabling and refeeding. So where is the gap for watchdog to trigger the timeout event in between after flashing and code start the execution. Somewhere i am getting interest on this point.

Regards,

Srinivas.v

[Kenneth]

Srinivas V said:

it means while erasing the complete code in flash will erase the  watchdog configuration and register settings as well

How do you draw this conclusion? It's not stopped or cleared by a flash erase/eraseall operation. So you need to eraseall, then power cycle the board, then reflash.

Kenneth

[Srinivas V]

Hi Kenneth, 

Thanks for your reply.

It means after flash erase/erase all operation we need to power cycle the board then reflash. After erase all operation without power cycle and with power cycle what is the difference. 

So after power cycle only it will update the WDT related UICR and other config Registers. please clarify me on this one.

Regards,

Srinivas.V

[Kenneth]

The watchdog peripheral is a independent peripheral, once started it will require to be fed, else it will timeout and trigger a watchdog reset. The only way to stop a watchdog is a "hard" reset (e.g power cycle). I do not understand why you are mentioning UICR, there is no dependency between UICR and watchdog.

Kenneth

[Srinivas V]

Hi Kenneth,

Once again thanks for your reply.

Yes there is no dependency between UICR and WDT and we need to feed to WDT all are fine. My doubt is,

1. We have completely erased the flash - no WDT Settings in Flash

2. We have reprogrammed the new Image with WDT Enabled - Flashing is done.

3. Restarting the board means through Debugger Reset Pin.

4. When we see the reset reason it shows as -Dog, At this stage the program still not reached the WDT Config Function, just resets the board and Reading the reset Register. in this case when and where the WDT is enabled, and why it is showing the Reset reason as -Dog.

Regards,

Srinivas.V

[Kenneth]

You need to specify what is happening before step 1. E.g. is there firmware with WDT before step 1?

Kenneth