This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52832 BLE radio not broadcasting

I have a project I've developed on a dev board, and everything works. When integrating this into a custom board and running the firmware, however, I'm not getting any BLE radio signal whatsoever. I'm flashing the same code and softdevice that I have been using on the dev board. I'm able to get into the device and see my debug code via JLink, everything seems to operate fine except the radio.

I've gone through several boards from the prototype assembler, and even taken a bare PCB and assembled my own, with no luck, so I'm fairly certain it isn't a build issue.

It's not impossible that it's a design issue, but as far as I can tell I've followed the reference and recommendations.

I found a post here where a guy had the same problem I'm having, and it was apparently due to the 32MHz crystal not having the correct tolerance. His was .5%, while NRF52832 requires 40ppm for BLE. My crystal is a CX3225SB32000D0FPLCC, which is 10ppm. I suppose it could be a different type of crystal issue, but as far as I can tell it should work.

I'm wondering if there's some sort of fuse config that factory fresh chips need. I'm really out of ideas.

Screen Shot 2017-03-11 at 10.42.46 AM.png

Parents
  • Hi,

    Not easy to debug HW issue through the forum;) but the usual differences between nRF5x boards preventing FWs to boot are:

    1. Different LF clock source (crystal/no crystal or faulty/not precise crystal).
    2. Different GPIO settings which is causing hard fault or other deadlock during start-up (e.g. when APP code assumes to initialize some serial or GPIOTE interface, reads button state etc.)
    3. Layout issue (usually cause by having too tight PCB real estate and not following Nordic design guidelines) causing problem with power source or nRF5x DCDC circuit.

    Debugging first one can be done by using synthesized LF clock from HF clock source during SD init (it's not officially tested by Nordic but it works). Debugging second issue can be done by removing all these sections before enabling SD and starting BLE Peripheral advertising (or simply by making sure that all GPIO values/links are correct). Third type of issue is hard to debug in FW, you can comment out DCDC enabling if you have it in the boot sequence (it helped me once to discover faulty HW design around DCDC components around nRF52).

    Cheers Jan

Reply
  • Hi,

    Not easy to debug HW issue through the forum;) but the usual differences between nRF5x boards preventing FWs to boot are:

    1. Different LF clock source (crystal/no crystal or faulty/not precise crystal).
    2. Different GPIO settings which is causing hard fault or other deadlock during start-up (e.g. when APP code assumes to initialize some serial or GPIOTE interface, reads button state etc.)
    3. Layout issue (usually cause by having too tight PCB real estate and not following Nordic design guidelines) causing problem with power source or nRF5x DCDC circuit.

    Debugging first one can be done by using synthesized LF clock from HF clock source during SD init (it's not officially tested by Nordic but it works). Debugging second issue can be done by removing all these sections before enabling SD and starting BLE Peripheral advertising (or simply by making sure that all GPIO values/links are correct). Third type of issue is hard to debug in FW, you can comment out DCDC enabling if you have it in the boot sequence (it helped me once to discover faulty HW design around DCDC components around nRF52).

    Cheers Jan

Children
No Data
Related