BLE Not Starting on Custom PCB (BC40C, nRF5340) – Possible Clock Problem?

[YeQuit]

Hi everyone,

I wanted to share an update on the BLE issue I’m experiencing with the BC40C (nRF5340) module on my custom PCB. I initially described the problem in this  Custom Board with BC40C (nRF5340) - Bluetooth won’t advertise after flashing Peripheral UART sample , where I suspected that the issue might be related to a missing or incorrect startup of the application core or network core.

However, based on recent tests, this now seems unlikely. The firmware runs correctly when using the same signals and firmware with the EV-BC40C evaluation board, which suggests that both cores are functioning as expected. This points instead to a possible hardware-level issue — such as a problem with the clock, power supply, or layout.

---

Project Background

I’m working on the second version (V2) of a prototype device that uses the Fanstel BC40C module for BLE communication. The first version (V1) worked well, including BLE functionality. For V2, I made the following changes:

• Reduced the PCB size

• Added I2C functionality

• Integrated an ADC

• Added a second status LED

Despite these relatively small modifications, BLE is no longer functioning on the new version (V2). The same firmware that worked on V1 does not initiate advertising on V2.

---

What I’ve Tried So Far

To isolate the issue, I performed the following test:

1. BC40C Soldered Directly on V2 PCB
   I flashed the same firmware onto the BC40C module soldered on the V2 board. The flashing process completes without any errors — even when flashing various BLE test programs (e.g., Peripheral UART, Blinky, custom firmware). The device responds to flashing as expected: for example, if I flash a Blinky program and then erase the chip, the LED stops blinking.

   Also, the LED behavior changes depending on which firmware is flashed, which further confirms that the firmware is running correctly. However, BLE advertising still does not start in any of the tested BLE samples.

2. Wiring the V2 PCB to the EV-BC40C Evaluation Board
   To rule out layout or component-level issues on the V2 PCB, I desoldered the BC40C from V2 and connected each relevant signal via wires from the V2 board to the corresponding pins on the EV-BC40C evaluation board. With the same firmware and the same electrical signals, BLE works perfectly in this setup.

This suggests that the issue may not be firmware-related but rather hardware-related — possibly something about the clock, power supply, or signal integrity on the V2 PCB.

---

A Curious Observation: LED Blink Frequency Difference

In both setups, an onboard status LED is used to indicate BLE state. I measured the blink intervals and noticed a consistent difference:

• EV-board wiring setup (where BLE works):
  Blink interval: ~1.3 seconds (~0.77 Hz)

• Directly on V2 PCB (where BLE does not work):
  Blink interval: ~0.74 seconds (~1.35 Hz)

This is nearly a factor of two difference in frequency — despite running the same firmware. This leads me to wonder:

Could this be a sign of a clock or oscillator issue that’s preventing BLE from working correctly?

---

Questions / Next Steps

Has anyone observed similar behavior before? Could a misconfigured or faulty external clock, or other hardware-level timing issue, explain both the faster LED blinking and the non-functioning BLE?

If needed, I can provide layout files, power measurements, or any other relevant information. I’d really appreciate any suggestions or ideas on what to check next!

Thanks for reading,

[Einar Thorsrud]

Hi,

When you write that BLE is not working, what exactly does that mean? How have you tested, and do you have any logging enabled? What does the log say? Also, have you done any debugging? What have you learned from the deubgging? Even if the issue may be HW related, we may be able to get usefull pointers from debugging.

that said, typical BLE related issues when changing the HW is related to oscillator configuration, as you have indicated:

• If everythign looks good from SW perspective but you cannot observe BLE advertising packets from the device even if it should be advertising and you see it does from debugging, that could indicate an inacurate HFXO frequency. A typical reason for this would be incorrect load capacitor values.
• If advertising packiets are recived correctly, but establishign and maintaining a connection is difficult or impossible and result in disconnect reason 0x3E ("Connection Failed to be Established"), this could point to a problem with the LF crystall oscillator (if using LFXO, the load caps around that).
• See here for information on how to configure the load capacitors (it depend on the SDK version, if using a recent SDK version, you do it in the devicetree)

[YeQuit]

Hi,

When I say “BLE is not working,” I mean that the device does not show up in the nRF Connect mobile app or any other BLE scanner, even though it should be advertising. The same firmware works perfectly on our V1 board (device shows up and connects), but on V2, it doesn’t appear at all.

I’ve tested various firmware examples, including ones from the BC40C module manufacturer. Flashing works without any issues on both versions — the LED behavior changes after flashing, and memory contents are updated correctly (verified via nRF Programmer). However, BLE advertising still does not happen on the V2 board.

Regarding Point 1 (HFXO & load capacitors):

The capacitor values are the same on V1 and V2. The only difference is that V2 uses 0402 components instead of 0603, but both are rated for 6.3 V, so that should not be an issue.

Also important to note:
We’re using the BC40C as a complete pre-certified module, so we did not modify or change anything related to the crystal oscillators — those are integrated into the module. The only external passives we placed are the decoupling capacitors, as recommended in the datasheet.

To rule out board-level issues, I also removed the capacitors on the boards and tested with the BC40C wired from the V2 board onto the EV-BC40C evaluation board as well as V1 — BLE only works when the module is running on the eval board or connected via wires. It does not work when running directly on the V2 PCB, regardless of the capacitors being present or not.

Regarding points 2 & 3 (Debugging & Logs):

I haven’t tried logging yet, but I will definitely look into it based on the information you provided. I’ll study how to enable and use logging in this context, and follow up with the output once I have results.

Thanks again for your helpful support!

[Einar Thorsrud]

Hi,

I see. I suggest progressing the following way:

1. Verify that you see this issue with more than one module in case it is a fault device.
2. Start logging and debuggign to verify that advertising is successfully started and that there are no errors.
3. If that does not reveal any issue, I suggest setting up a carrier using the radio test sample and verifying the frequency with a specrtrum analyzer. This will show if the HFXO is behaving properly. If it is not, I would start by checking if there are clock differences between the two versions of the module, that lead to there perhaps being a need for a different load capacitor configuration.