NRF52832 BLE radio not broadcasting

[mlsor]

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

[endnode]

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

[mlsor]

Thanks for the input. I'll look through these things. It does boot and all of the functionality is there, but there is just no radio whatsoever. The layout was derived from the reference radio board layout from Nordic.

For the LF crystal, I actually have two software builds, one that uses the internal RC and another that uses the external. I was using it to determine the power savings difference. Both work with the custom board.

I'm using a timer, FDS, GPIO, it all works. I'm not using the GPIO near the radio. I tried a few different capacitance values with the HF crystal, though I assume nothing would work if this wasn't oscillating.

UPDATE: The PCB assembler provides parts libraries for their "favorite" stocked parts. It turns out that the part layout for the crystal I'm using has the pins swapped as though the person who designed it thought the 'top view' in the data sheet was a view from the bottom. I was able to turn the part 90 degrees to get the ground and clock corners to align correctly and all is well.

Between this and the other issue linked in the original post, if you are reading this because you can't see your radio, but everything else seems to be working fine, it is most likely an issue with your high frequency clock. The NRF52 will fall back to its internal HF oscillator (HFINT) if the crystal is not oscillating and your code will likely be none the wiser. To verify that the high frequency crystal is working, you can add something like this to your code after the softdevice is set up, but before you do anything that requires the radio:

err_code = sd_clock_hfclk_request();
APP_ERROR_CHECK(err_code);

uint32_t hfclk_is_running = 0;

while (!hfclk_is_running) {
    APP_ERROR_CHECK(sd_clock_hfclk_is_running(&hfclk_is_running));
}

The code above would block until the HF clock is started, and in my example it would pass on the dev board but block indefinitely on my board, until I fixed the crystal orientation. In my opinion, any library that would want to use the radio **cough BLE stack ** should have a variant of this and return an error on initialize if the HF clock (or any other dependency) is not working.

[endnode]

Oh I've misunderstood that your FW is not starting at all after moving to custom board. This really looks like antenna/matching network problem. So SD init and enable functions return success and all other SD calls are working? I would try some pre-compiled examples from nRF5 SDK and if symptoms are similar then it really looks like layout/population issue.

[mlsor]

Yeah, I think there must be something going on, but even with a bad layout I'd expect a few centimeters of range. I've posted the antenna layout and network, it is from the reference design. That's why I was wondering if perhaps there may be some sort of fuse or register required to be set to enable the radio, something that would have come from the factory with the reference board but not with a chip from factory.

[mlsor]

Ok, now I'm a bit confused. I thought that having the LF clock set to the internal RC would be enough to know that the HF crystal was working. Based on the post I mentioned in the original comment, I am thinking that the HF crystal is absolutely required for the radio. However, I completely removed the HF crystal from the board, and it hasn't changed anything; flash reads/writes still work, timers, softdevice init, GPIO driving the stepper motor, it all works as before. Short of having a fairly high bandwidth probe (mine is only 60 MHz 10x probe), how can I tell that the HF oscillator is up? Is there something besides the lack of radio that I can use to troubleshoot it? I feel like perhaps I'm on to something here...