RTC fails to wake chip from SystemON Sleep nrf52840

[EMPConner562]

Hello,

We have a product that sends out an ESB message approximately ever second, it does this using the RTC timer with the following setting:

static void rtc_config(void)
{
    uint32_t err_code;

    //Initialize RTC instance
    nrf_drv_rtc_config_t config = NRF_DRV_RTC_DEFAULT_CONFIG;
    config.prescaler = 4095;
    err_code = nrf_drv_rtc_init(&rtc, &config, rtc_handler);
    APP_ERROR_CHECK(err_code);

    //Enable tick event & interrupt
    //nrf_drv_rtc_tick_enable(&rtc,true);

    //Set compare channel to trigger interrupt after COMPARE_COUNTERTIME seconds
    err_code = nrf_drv_rtc_cc_set(&rtc,0,COMPARE_COUNTERTIME * 8,true);
    APP_ERROR_CHECK(err_code);

    //Power on RTC instance
    nrf_drv_rtc_enable(&rtc);
}

It sends the message then, goes into SystemOn sleep using the power manage function:

void power_manage( void )
{
    __WFE();
    __SEV();
    __WFE();
}

We had a batch go out and now a month later they have all stopped functioning, we believe that the processor is stuck in systemOn sleep as the included 3V cell batteries still have charge.

Has anyone come across a similar issue in the past or has any idea how to debug this?

One idea we have had is running a watchdog timer to make sure that the process never stalls for more than 2 seconds, but would still be nice to know what's causing the issue.

Any help appreciated!

[ovrebekk]

Hi

I can't remember seeing reports of this issue earlier. 

Does it start working again if you remove and re-insert the battery? 

What is the voltage over the batteries?

Could you show me how the RTC interrupt is handled?

Best regards
Torbjørn

[EMPConner562]

Hello,

This is this first time i'm posting about the issue?

The battery is soldered in, so I've removed and then re-soldered the battery and the device didn't start working again, with the one i tested.

The voltage on the batteries is close to the nominal 3V.

This is the RTC handler code:

static void rtc_handler(nrf_drv_rtc_int_type_t int_type)
{
    if (int_type == NRF_DRV_RTC_INT_COMPARE0)
    {
       nrfx_clock_hfclk_start();
       gpio_check_and_esb_tx();
       nrf_drv_rtc_counter_clear(&rtc);
       nrf_drv_rtc_cc_set(&rtc,0,COMPARE_COUNTERTIME * 8,true);
    }
}

One other thing that I've since found out is that the ones in production were programmed with the nRFgo Studio, with Read back protection enabled. These are the devices that appear to have failed. I also enabled read back protection in the following way in code:

    if (NRF_UICR->APPROTECT != 0x0)
    {
    NRF_NVMC->CONFIG = 0x1;
    NRF_UICR->APPROTECT = 0x0;
    NRF_NVMC->CONFIG = 0x0;
    }

I have setup a test to see if enabling the read back protection in nRFgo Studio has any affect on the crash. I have programmed three devices one with segger, one with nRFgo without the read back protection, and one with nRFgo Studio with read back protection. 

After letting these run from Wednesday, I have checked them again today and only the one programmed with nRFgo Studio with read back protection has stopped working. This could be a coincidence however I now believe this to be the issue.

Is there any reason that you can think of that this might cause such an issue?

Kind regards

Conner

[ovrebekk]

Hi Conner

EMPConner562 said:

This is this first time i'm posting about the issue?

Seems so, yes. My point is that I can't remember anyone else posting about similar issues either, so it's not a known issue to us. 

EMPConner562 said:

One other thing that I've since found out is that the ones in production were programmed with the nRFgo Studio, with Read back protection enabled. These are the devices that appear to have failed.

This might explain it. nRFgo Studio is very old, and is not recommended for use with the nRF5 series. I would strongly suggest using nrfjprog instead, and make sure you have up to date JLink drivers.  

EMPConner562 said:

I also enabled read back protection in the following way in code:

When writing to the flash it is important to check the state of the READY register before and after each operation. For reference I have included a code snippet from the system_nrf52840.c file to illustrate this:

#if defined (CONFIG_GPIO_AS_PINRESET)
    if (((NRF_UICR->PSELRESET[0] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos)) ||
        ((NRF_UICR->PSELRESET[1] & UICR_PSELRESET_CONNECT_Msk) != (UICR_PSELRESET_CONNECT_Connected << UICR_PSELRESET_CONNECT_Pos))){
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NRF_UICR->PSELRESET[0] = 18;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NRF_UICR->PSELRESET[1] = 18;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren << NVMC_CONFIG_WEN_Pos;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
        NVIC_SystemReset();
    }
#endif

Best regards
Torbjørn