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