Reset with hard fault after bluetooth advertising

[simoiamma]

Goodmorning,

I have a problem with ble advertising on nrf52840.

I'm using a custom board using "zephyrOS v3.3.99-ncs1-1" and "nrf connect SDK v2.4.2".

An hard fault occours just after the system starts advertising and resets with RESETREAS = 4 (soft reset).

From the ble log:

E: MPSL ASSERT: 112, 2134
E: ***** HARD FAULT *****
E: Fault escalation (see below)
E: ARCH_EXCEPT with reason 3

E: r0/a1: 0x00000003 r1/a2: 0x20009028 r2/a3: 0x80000000
E: r3/a4: 0x00000001 r12/ip: 0x200053ba r14/lr: 0x00031863
E: xpsr: 0x41010018
E: Faulting instruction address (r15/pc): 0x0003186e
E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x200033a8 (unknown)
E: Resetting system

This problem shows only for some boards so could be hardware related (i.e. problem with warm up time of low power external crystal oscillator?).

Anyone have any suggestions?

Thanks,

Simone

[Simonr]

Hi

This assert should be raised if the HF crystal is not running when it should be, and could indicate that the crystal oscillator ramp-up is too slow or that there's an issue with the HF crystal.

If it occurs just in some boards, what are the load capacitors set as on these boards. Another common issue is that the HF crystal is soldered on 90 degrees off, so that the GND pads are on the crystal pads and vice versa.

You can also try to measure the crystal's startup time. You can use the use the code snippet below for this (must be run before bt_enable()).

	NRF_TIMER1->BITMODE = TIMER_BITMODE_BITMODE_32Bit << TIMER_BITMODE_BITMODE_Pos;
	NRF_TIMER1->TASKS_CLEAR = 1;
	NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
	NRF_TIMER1->TASKS_START = 1;
	NRF_CLOCK->TASKS_HFCLKSTART = 1;
	while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
	NRF_TIMER1->TASKS_CAPTURE[0] = 1;

	printk("HF Clock has started. Startup time: %d uS\n", NRF_TIMER1->CC[0]);

Also, are you using mpsl_clock_hfclk_latency_set() in your code?

Best regards,

Simon

[simoiamma]

Hi Simonr,

I've noticed that the ramp up time changes once in a while: tipically is about 350us but sometimes goes up to 700us.

However, it was a problem of ramp up time of the external crystal oscillator. Starting it before the BLE subsystem solved the  problem.

Thanks

Simone

[Simonr]

Glad to hear that you were able to resolve this issue! Let me know if you have any further questions.

Best regards,

Simon