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

bt_enable within peripheral_ht sample crashing only on custom 52840 board

We are working on a combination 52840/9160 board, and after having much success with most software components, have run into a roadblock with the more complex Bluetooth samples using the Zephyr drivers.  The "beacon" sample works excellently on our custom board using the 52840, giving a signal of -20dBm viewed through the nRF Connect App.  The PCA10090 and a Sparkfun 52840 board are also working well with this sample.  In addition, "scan_adv" seems to function on all three boards.  The problem comes when trying to use a peripheral or more advanced type of Bluetooth sample such as "peripheral_ht" or "eddystone".  The two storebought boards work, but our custom board seems to hang on or never return from the "bt_enable" call, and the current draw to the board is unusually low compared to normal (1.7mA, even with a number of other ICs present).

We have a USB connection on our custom board using the ACM driver, and this seems to work very well to create debugging ports that can be viewed in "minicom".  But USB often gives errors on these more complex Bluetooth samples, disconnecting only if "minicom" is not already open.  We have not seen these issues with any other samples or code, and this leads us to believe that the software may be crashing.  The USB connection shows decent logging on the Sparkfun board and the "peripheral_ht" sample works well on it and the PCA10090 as mentioned.

We made our own board directory (after quite a bit of effort/learning), but we doubt this is contributing to the problem, because we tried flashing the Sparkfun board's result right to our own board and the same thing happens.  We are thinking it could be a hardware problem somehow, but are not sure how to debug it.  We use the same antenna as PCA10090 (very difficult to obtain, we may have the last few in the world) with a B39242B8852P810 SAW filter and carefully-designed matching circuitry.  The "beacon" sample even advertises fine to the nRF Connect App with the Bluetooth antenna desoldered, although the signal is 25-30dB weaker.  We do not believe the problem is reception-related because this should not cause the software to fail.

Our only guesses at this problem are that maybe there is an infinite loop waiting for something to happen, and this never returns (but why mess up USB?), or perhaps something to do with crystal stability or GPIO levels.  The 52840 chip revisions seem to be marked "C0" on both the PCA10090 and our own board.  The regulated voltages seem to be normal on our 52840, and we used the recommendations in the documentation for designing the circuit.  None of the existing errata seem to apply.  We could ask the Zephyr team as well, but it is odd that the code works on one 52840 and not another (and we are also in a bit of a time crunch).

  • Hi,

     

    The two storebought boards work, but our custom board seems to hang on or never return from the "bt_enable" call, and the current draw to the board is unusually low compared to normal

    Do your boards have an external 32k? The default is to choose that in the bt samples.

    Try setting CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC and see if this has an impact on the issue.

     

    Kind regards,

    Håkon

  • Thank you Håkon!  That was it!  The SYNTH one also works, and we would probably disable Bluetooth before shutting off the main clock, so using it should be okay (but we will see).  It is probably more accurate than the RC module, but we wonder what the implications of this accuracy are?  Is the RC module only present to keep Bluetooth running somehow while the processor is sleeping?  Anyway, thank you again!

Related