nRF52832 BLE Works Once, Then Fails – Stuck in HFCLK Initialization

[Red J.]

Hi everyone!

I'm having trouble getting a custom PCB with the nRF52832 chip to work, specifically with enabling BLE functionality.

It seems there are issues related to the HFCLK (High-Frequency Clock). I tried running a sample test code I found in the forums, but it gets stuck in the following while loop:

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;

After several weeks of troubleshooting, I soldered a new board, and the first time I flashed it, the BLE application ran perfectly. However, on the second boot, it stopped working, and if I run the above code again, it still gets stuck at the same spot.

The hardware design follows the recommended guidelines from the documentation. The rest of the program seems to run fine, and the power supply current has never exceeded 14mA at 3V.

Does anyone have any ideas on what could be causing these issues or where I should investigate further?

Thanks for your help!

P.S.: By the way, when I attempt to log via RTT, I get this error:

00> [00:00:01.618,621] <err> os: ***** HARD FAULT *****
00> [00:00:01.618,621] <err> os:   Debug event
00> [00:00:01.618,652] <err> os: r0/a1:  0xfffffff5  r1/a2:  0xe000ed00  r2/a3:  0x20003844
00> [00:00:01.618,652] <err> os: r3/a4:  0x00000001 r12/ip:  0x00000004 r14/lr:  0x00027ae1
00> [00:00:01.618,682] <err> os:  xpsr:  0x61000000
00> [00:00:01.618,682] <err> os: Faulting instruction address (r15/pc): 0x00011000
00> [00:00:01.618,743] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:01.618,774] <err> os: Current thread: 0x20002be0 (unknown)
00> [00:00:02.485,076] <err> os: Halting system

Any idea what might be causing this? I also saw the same error when it ran successfully.

[Simonr]

Hi

I think that this HFCLK detection might be causing this as it is likely halting or causing the HF clock to drift. Have you tried running any of the samples without this piece of code to see if you can recreate it then?

Best regards,

Simon

[Red J.]

Hi,

Sure, I only applied this code for debugging after I couldn't get it to work with a sample default configuration.

Best regards.

[Simonr]

But do you still run into this hardfault with the HFCLK detection disabled, or do you then only run into the immediate disconnect issue?

Figuring out what the hardfault is caused by would be the first step. Then possibly getting a sniffer trace of what's going on over the air when you see these immediate disconnects. You can use a spare DK and the nRF Sniffer firmware + Wireshark to get a sniffer trace of what's going on over the air and upload it here so we can review it.

Best regards,

Simon

[Red J.]

Hi Simonr,
Yes, I activated the HFCLK detection only after this hardfault showed up. In fact, when the detection is activation it gets stuck there.

I'm doing that test as soon as possible. in the meantime, I have ordered a new PCB with some clock layout upgrades.

I'll keep you updated.

Thank you.