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

[Kenneth]

I am not sure how much time we should spend on this. But I did try a very simple main() where I simple read, output and cleared resetreas. Nothing else in main(). I am not able to see watchdog reset set on startup, are you sure your application is not enabling watchdog at any time, and when you are programming the watchdog timeout?

[Srinivas V]

Hi Kenneth,

Once again thanks for your reply. we both are not getting into point what i am expecting, here two  scenarios with the same code base i am explaining,

1. Just Reset the board and Read the Reset reason output and clear , the output showing Reset Reason as "-RESETPIN".

2. Completely erase the board and reflash it again and after that Read and output and clear the Reset Reason , in this case the out put showing Reset Reason as "DOG".

3. Yes , in our application we are enabled the Watchdog timer in the main function and in while loop we are re feeding every time, i am adding the code snippet for that 

void main()
{   log_init();                                                         //NRF log    
    hal_timers_init();                                                  //HAL Timers Init
    leds_init();                                                        //NRF LED's Init
    power_management_init();                                            //NRF Power Management Init
    (void)UTL_get_resetreason();                                              //HAL Rese Reason
    nrf_power_resetreas_clear(nrf_power_resetreas_get());               //NRF Clear after reset
    hal_rtc_initialize();                                               //HAL initialization of RTC2 for calender.
    ble_sb_initialize();                                                //HAL BLE Init
    hal_scheduler_init();                                               //NRF Scheduler Init
    nrf_mem_init();                                                     //NRF Memory Init
    hal_eeprom_initialize(&config);                                     //HAL EEPROM Init
    nrf_crypto_init();                                                  //NRF Crypto Init
    rtcInterfaceInit();          				                        //APP RTC Init for calender time
     
    hal_Wdt_Config_Enable();
    Read_Error_log_Write_Index();
    Update_Error_Diag_Log_Reset_Reason_Data();
    
    // Enter main loop.
    for (;;)
    { 
        sb_main();                                                                     //SB SoftBroker Main
        hstForeverReadAndHandoffNextPacket();                                          //HAL ECI Receive
        //if ((false == hal_ble_connection_state()) || (CDsIsStillCardData()))         // TODO Will see it later is it really required OR not.
        hstComTaskFxn();                                                               //HAL ECI Com Task
        idle_state_handle();                                                           //NRF idle state handling
        app_sched_execute();                                                           //NRF scheduler  
        hal_Wdt_Feed();                                                                //Re-feeding at the end of the while loop every time.
    }
}

Here our doubt was why we are getting Reset Reason as "DOG",as explained in 2 Point, instead of 

"-RESETPIN", or after erase and Flash by default it should show the Reset Reason as "-DOG" Only, just need clarification on this that sit. Actually QA Team has raised one issue on this , just need clarification from Nordic People, based on that we will close the Defect.

Regards, 

Srinivas.V

[Kenneth]

I suggest to change to:

2. Completely erase the board, POWER CYCLE THE BOARD, and reflash it again and after that Read and output and clear the Reset Reason , in this case the out put showing Reset Reason as "???".

[Srinivas V]

Hi Kenneth,

Thanks for your reply.

we have followed the sequence what you have suggested in previous reply in point 2.

2. Completely erase the board, POWER CYCLE THE BOARD,  and reflash it again and after that we have Read and output and clear the Reset Reason. In this case the out put showing Reset Reason as "-RESETPIN" , not as "DOG".

If we do the Flash erase, Reflash the New Image and POWER CYCLE THE BOARD, in this sequence we are getting the Reset Reason as "-DOG"

What is difference between these two sequences, if we do flash without power cycle what's happened inside the Registers. Can you please give me or explain the difference.

Regards,

Srinivas.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