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

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

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