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

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.

  • So, the system is halting for some reason here, and I'm inclined to think it's either due to a soldering issue (on the HF clock or the nRF52 SoC), or that the HF clock is loaded incorrectly.

    Have you had the custom board HW design reviewed by a Nordic engineer? If not, that might be a good place to start. You can create a private ticket here on DevZone and upload your schematics (pdf) and PCB files (gerber files) there.

    Here are some common issues with custom designs:

    • HF crystal is soldered on 90 degrees off, so the GND pads are on the clock pads and vice versa.
    • The HF crystal isn't loaded correctly. Optimally the load capacitors should be the value of Ccap in the following formula, where CL is the load capacitance of the crystal in the datasheet. Ccap = 2 * CL - 4pF
    • Some pins on the nRF52832 isn't soldered correctly and thus the nRF52832 isn't behaving as expected. Please double and triple check all the soldering pads.
    • The HF clock could drift or be disturbed by noise due to a bad ground layer on your custom PCB. Make sure there are plenty of vias between the GND layers and that there aren't any "lone" areas that aren't well connected to GND.

    Best regards,

    Simon

  • Hi Simonr,

    HF crystal orientation and Ccap have been checked and look fine.

    Soldering has been redone.

    I’m creating a new ticket today for a hardware revision.

    Despite these efforts, the system keeps showing the same issue.

    I have tried using the Zephyr link layer controller by adding CONFIG_BT_LL_SW_SPLIT=y to prj.conf, and it starts to advertise. I’ve searched but couldn’t find much on the implications of using this stack instead of SoftDevice.

  • Hi

    Just to make sure we're on the same page, does the application work as expected with the Zephyr controller, but not with the SoftDevice controller? What SDK version are you using for development exactly here?

    Best regards,

    Simon

  • Hi Simonr,

    nRF Connect SDK v2.7.0
    Toolchain v2.7.0

    As far as I know, executing BLE samples didn’t work, and the process seemed to get stuck during HFCLK initialization.

    When I added CONFIG_BT_LL_SW_SPLIT=y (experimental option, as far as I know, it uses the Zephyr stack for BLE), the devices started advertising, and I could connect. However, I still haven’t been able to bond.

    Regards

  • Hi

    This all sounds incredibly strange. The Zephyr stack is not experimental btw, and both should work fine Both with and without bonding. Let me know how the HW review case goes, as I'm hesitant to dive any deeper before confirming whether this is a HW issue or not.

    You could upload the board file you're using in NCS for your custom board, so we could have a look at that as well.

    Best regards,

    Simon

Related