This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

analyze reboot reason

Hello

in order to analyze reboot reson (HW \ SW) I use the following: 

in case of kernel crash I usually get coldstack print, in this case I can analyze and understand the issue, this case is OK

in other cases I just get reset device, without any print to console

in this case I read RESETREAS register and anylize.

in case I get "DOG", ok reason is clear, but usually I get "SREQ", what does it mean? 

btw, I could not find an analysis implmentation for nrf9160, so I wrote the following procedure, please varify I am not missing more options

static void log_resetreason(u32_t rr)
{
/* Reset reason */
LOG_INF("Reset reasons:");
if (0 == rr)
{
LOG_INF("- NONE");
}
if (0 != (rr & NRF_POWER_RESETREAS_RESETPIN_MASK))
{
LOG_INF("- RESETPIN");
}
if (0 != (rr & NRF_POWER_RESETREAS_DOG_MASK ))
{
LOG_INF("- DOG");
}
if (0 != (rr & NRF_POWER_RESETREAS_SREQ_MASK ))
{
LOG_INF("- SREQ");
}
if (0 != (rr & NRF_POWER_RESETREAS_LOCKUP_MASK ))
{
LOG_INF("- LOCKUP");
}
if (0 != (rr & NRF_POWER_RESETREAS_OFF_MASK ))
{
LOG_INF("- OFF");
}

if (0 != (rr & NRF_POWER_RESETREAS_DIF_MASK ))
{
LOG_INF("- DIF");
}

}


u32_t rr = nrf_power_resetreas_get(NRF_POWER);
log_resetreason(rr);

  • Hi,

     

    in case I get "DOG", ok reason is clear, but usually I get "SREQ", what does it mean? 

    That is a soft reset, usually via firmware triggered reset (NVIC_SystemReset()):

    https://infocenter.nordicsemi.com/topic/ps_nrf9160/power.html?cp=2_0_0_4_2_0_0_13#register.RESETREAS

     

     The default behavior when you get an assertion or a fault in zephyr is to print the failure on serial and then do a soft-reset. Do you get a printed failure message or similar before it rebooted?

     

    Kind regards,

    Håkon

  • no, I do not get a print .

    as I said, on some cases I do get failure and then kernel error prints , followed by resset. that's easy to analyze, I can always read crash prints, look at the map file , find the code in the relevant address and fix the issue

    the problem is that some of the time I just get a reset without any warning.

    one option: HW releted reset, may be due to the power cunsumption peaks of the modem

    second option: some SW related reset

    si I would like to know how can I best use the RESETREAS and any other means I have to analyze reset cause and source

    thank you 

  • Hi,

     

     

    kamacode said:
    one option: HW releted reset, may be due to the power cunsumption peaks of the modem

     This will show the reset value of RESETREAS, which is "none" in your implementation as it is now.

     

    kamacode said:

    as I said, on some cases I do get failure and then kernel error prints , followed by resset. that's easy to analyze, I can always read crash prints, look at the map file , find the code in the relevant address and fix the issue

    the problem is that some of the time I just get a reset without any warning.

     To catch this, you need to debug the actual failure, and not the reset cause. The fault itself might cause the serial print to fail.

    Try adding blocking assertions (for debug reasons), by setting CONFIG_RESET_ON_FATAL_ERROR=n (do this for secure region as well) and see if you can catch the fault.

     

    Kind regards,

    Håkon

Related