nrf5340: Halt on bus fault instead of reset

[Mike Mascari]

Good afternoon.

Hopefully a simple config-related question.

We have an nrf Connect 1.6.1 SDK-based app which performs simultaneous ble advertising and scanning. We have been chasing a ghost where the module becomes unresponsive a small percentage of the time (i.e.: 1% of modules). We're not certain of the bluetooth environment necessary to reproduce this state, but we were able to at least connect via gdb to a nrf5340-based module via JLink SWC when one entered this unresponsive state. When connected via gdb, doing a backtrace yielded:

(gdb) bt
#0 z_arm_reset ()
at /ncs/zephyr/arch/arm/core/aarch32/cortex_m/reset.S:69

That code is assembly which reads:

/*
* The entry point is located at the z_arm_reset symbol, which
* is fetched by a XIP image playing the role of a bootloader, which jumps to
* it, not through the reset vector mechanism. Such bootloaders might want to
* search for a __start symbol instead, so create that alias here.
*/
SECTION_SUBSEC_FUNC(TEXT,_reset_section,__start)

#if defined(CONFIG_INIT_ARCH_HW_AT_BOOT)
/* Reset CONTROL register */
movs.n r0, #0

JLink RTT Viewer was logging to the terminal at the time it entered this state, and, of course, stopped logging:

[00:00:01.897,155] <inf> advertise: ping
...
[00:00:28.627,716] <inf> advertise: ping
[00:00:29.617,736] <inf> advertise: ping
[00:00:30.607,757] <inf>

Once we entered "continue" into gdb, the device rebooted:

[00:00:30.607,757] <inf> [00:21:46.013,580] <err> os: ***** BUS FAULT *****
[00:21:46.013,854] <err> os: Instruction bus error
[00:21:46.014,160] <err> os: r0/a1: 0x00000000 r1/a2: 0x20008980 r2/a3: 0x2000c190
[00:21:46.014,587] <err> os: r3/a4: 0x00000000 r12/ip: 0x000014d0 r14/lr: 0x0003b11f
[00:21:46.015,014] <err> os: xpsr: 0x61040000
[00:21:46.015,289] <err> os: Faulting instruction address (r15/pc): 0x01027db0
[00:21:46.015,686] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:21:46.016,052] <err> os: Current thread: 0x200095d8 (BT RX)
[00:21:46.026,397] <err> fatal_error: Resetting system

Our question: What configuration option(s) is/are required so that the module will ALWAYS reboot, instead of entering the halted state as it did? Looking at our build, CONFIG_RESET_ON_FATAL_ERROR is y.

Thank you!

[Kenneth]

Hello,

You are working on a rather old nRF Connect SDK, but please try to implement these two workarounds:
https://infocenter.nordicsemi.com/topic/errata_nRF5340_Rev1/ERR/nRF5340/Rev1/latest/anomaly_340_160.html 
https://infocenter.nordicsemi.com/topic/errata_nRF5340_Rev1/ERR/nRF5340/Rev1/latest/anomaly_340_161.html 

Best regards,
Kenneth

[Mike Mascari]

Thank you Kenneth. 

I attempted to migrate our app code to the latest nRF Connect SDK, but ran into challenges. Sorry to ask for hand-holding, but could you tell me which files in 1.6.1 should have the code added as specified in the 160 and 161 errata? Not sure exactly where to drop in those lines.

[Kenneth]

Hello,

Regarding implementing errata 161:
https://infocenter.nordicsemi.com/topic/errata_nRF5340_Rev1/ERR/nRF5340/Rev1/latest/anomaly_340_161.html 

The errata says you should replace the following code:

NRF_RESET->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Release;

with the following

*(volatile uint32_t *) 0x50005618ul = 1ul;
NRF_RESET->NETWORK.FORCEOFF = (RESET_NETWORK_FORCEOFF_FORCEOFF_Release << RESET_NETWORK_FORCEOFF_FORCEOFF_Pos);
delay_us(5); // Wait for at least five microseconds
NRF_RESET->NETWORK.FORCEOFF = (RESET_NETWORK_FORCEOFF_FORCEOFF_Hold << RESET_NETWORK_FORCEOFF_FORCEOFF_Pos);
delay_us(1); // Wait for at least one microsecond
NRF_RESET->NETWORK.FORCEOFF = (RESET_NETWORK_FORCEOFF_FORCEOFF_Release << RESET_NETWORK_FORCEOFF_FORCEOFF_Pos);
*(volatile uint32_t *) 0x50005618ul = 0ul;

I can see this require one change, for the board file (will depend on the board you have):
https://github.com/NordicSemiconductor/nrfx/blob/master/hal/nrf_reset.h#L137 

Regarding implementing errata 160:
https://infocenter.nordicsemi.com/topic/errata_nRF5340_Rev1/ERR/nRF5340/Rev1/latest/anomaly_340_160.html 

I can see this require two changes:
https://github.com/nrfconnect/nrfx/blob/master/mdk/system_nrf5340_application.c#L172 
https://github.com/nrfconnect/nrfx/blob/master/mdk/system_nrf5340_network.c#L85 

Hope this helps,
Kenneth

[Mike Mascari]

Hi Kenneth. 

Our board initialization code invoked by SYS_INIT at POST_KERNEL was doing:

NRF_RESET->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Release;

 

When we replaced that with the 161 errata from nrf_reset.h:

	*(volatile uint32_t *)0x50005618UL = 1UL;
        NRF_RESET->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Release <<
	  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
        NRFX_DELAY_US(5);
        NRF_RESET->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Hold <<
	  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
        NRFX_DELAY_US(1);
        NRF_RESET->NETWORK.FORCEOFF = RESET_NETWORK_FORCEOFF_FORCEOFF_Release <<
	  RESET_NETWORK_FORCEOFF_FORCEOFF_Pos;
        *(volatile uint32_t *)0x50005618UL = 0UL;

the board continually reboots. Should I leave board.c's initialization alone and just patch nrf_reset.h with the expectation that something is invoking nrf_reset_network_force_off? Confused.

- Mike

[Kenneth]

Mike Mascari said:

Should I leave board.c's initialization alone and just patch nrf_reset.h with the expectation that something is invoking nrf_reset_network_force_off? Confused.

Sounds like a good idea. But to understand more about the cause of the error here you can add the following to you application prj.conf:

CONFIG_ASSERT=y
CONFIG_ASSERT_VERBOSE=y
CONFIG_ASSERT_NO_COND_INFO=n
CONFIG_ASSERT_NO_MSG_INFO=n
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_NAME=y

I suspect the problem is that the code is executed from nonsecure environment, and this cause a security exception that reset the system.

Best regards,
Kenneth