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.

[Red J.]

Hi Simonr,

Hardware Revision: (Case ID: 336239)

I have tested with new Ccap values and soldered a new board, but the issue seems to persist. Some issues have arisen during the revision, but they are related to the RF line of the antenna. However, under very specific conditions, the device has been connectable.

I am testing two board configurations:

1. A custom board built from scratch, which doesn’t work very well.
2. The nRF52DK_nRF52832 board, with LEDs and button options disabled, as well as some other configurations like disabling the DCDC.
   
   

Recap:

The standard examples to run Bluetooth don’t work. I used the following code to check the HFCLK startup time, but it gets stuck in the 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;

When running the default SoftDevice Bluetooth stack, the following error occurs after starting advertising:

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

I disabled the log and printk modules in case they were interfering with Bluetooth functionality, but it made no difference.

I enabled the option CONFIG_BT_LL_SW_SPLIT=y to use the Zephyr stack.

If I run the HFCLK detection code, it still gets stuck in the loop.

If I run the program without that check, the device starts advertising and becomes connectable. The functionality is a bit unstable—sometimes it only works while debugging, other times only when not debugging. Occasionally, it disconnects quickly. However, I have managed to establish a connection in some instances.

Thank you for all your help!

[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.