Device crash when doing a software reset

[bdlr2]

I'm developing a software with the nRF Connect SDK v2.5.1. This software runs Matter on the nRF5340.

I need to reset the MCU from my app. To do so, I use the sys_reboot(SYS_REBOOT_COLD) function. But this makes the OS crash with the following trace:

uart:~$ E: IPC endpoint bind timed out
ASSERTION FAIL @ WEST_TOPDIR/zephyr/drivers/ieee802154/ieee802154_nrf5.c:1153
E: r0/a1:  0x00000004  r1/a2:  0x00000481  r2/a3:  0x2000ca30
E: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x00023e0f
E:  xpsr:  0x69100000
E: s[ 0]:  0xffffffff  s[ 1]:  0x000134c5  s[ 2]:  0x00000000  s[ 3]:  0x00038607
E: s[ 4]:  0x00008000  s[ 5]:  0x000aeab4  s[ 6]:  0x000a6548  s[ 7]:  0x000aebf0
E: s[ 8]:  0x00000000  s[ 9]:  0x00072377  s[10]:  0x00008000  s[11]:  0x20027404
E: s[12]:  0x20002f40  s[13]:  0x00023e05  s[14]:  0x000ac36c  s[15]:  0x000aeab4
E: fpscr:  0x00000481
E: Faulting instruction address (r15/pc): 0x00072362
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x2000ca30 (main)
E: Halting system

Is there a way to make it better ?

[Susheel Nuguru]

It might be an issue in our MDK, 

Putting breakpoint in ncs\v2.5.2\modules\hal\nordic\nrfx\hal\nrf_reset.h-> nrf_reset_network_force_off->nrf53_errata_161() seems to still evaluate as false. That means this errata_161 workaround still does not seem to be applied on the app core of nRF53. Can you brute force this workaround for testing and see if you see any difference? Change the function as below for testing it on nRF53

NRF_STATIC_INLINE void nrf_reset_network_force_off(NRF_RESET_Type * p_reg, bool hold)
{
    if (hold)
    {
        p_reg->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Hold <<
                                  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
    }
    else /* Brute force the errata workaround on any core */
    {
        *(volatile uint32_t *)0x50005618UL = 1UL;
        p_reg->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Release <<
                                  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
        NRFX_DELAY_US(5);
        p_reg->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Hold <<
                                  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
        NRFX_DELAY_US(1);
        p_reg->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Release <<
                                  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
        *(volatile uint32_t *)0x50005618UL = 0UL;
    }
}

Do a prestine build again see if there is any difference.

[Susheel Nuguru]

BTW, which version of nRF5340 do you have? Can you write me the full code laser markings on the nRF chip?

[bdlr2]

The full marking of my chip is as follows:

NRF5340

QKAAD0

2233BL.

I tried your fix: the nrf53_errata_161 is properly applied actually. My mistake was not to call nrf_reset_network_force_off before the sys_reboot.

That leads to a deeper issue in the Matter stack because in modules/lib/matter/src/include/platform/internal/GenericPlatformManagerImpl_Zephyr.ipp, sys_reboot is called alone too.

[Susheel Nuguru]

Thanks for the info.

I think you have found a bug in the matter code. I will report this to the team. Thanks for the help.

[bdlr2]

I proposed a fix here Fixed PlatformMgr().Shutdown() for NRF53 by bdlr2 · Pull Request #390 · nrfconnect/sdk-connectedhomeip (github.com)

[Susheel Nuguru]

Awesome. Thanks for your contributions. This is the right way to suggest a change in the SDK. +1 to you.