Hi!
We're working on a development project using nRF52832. Our original prototyping PCBs used the nRF52832-QFAA. On these boards, the nRF worked without issues, and we could debug while using BLE even with multiple connections.
We later moved on to the final boards, which are much smaller and use a different package: NRF52832-CIAA-R. The firmware works just fine, as expected since it's the same silicon. However, we found that when the debugging session is active, BLE dies completely. The device doesn't advertise at all, so new connections are impossible and, if a connection is active when the debugging session starts, it promptly disconnects.
The RTT output looks just fine, the nRF seems to believe that everything is going as usual. It says it's advertising and even logs the disconnection event. As soon as the debugging session is stopped (either from Segger or RTT viewer or by removing the connector) the BLE signal comes back again. The advertising is seen by scanners and the device is connectable.
We suspected that the debugging traces could be injecting some noise into the RF traces, so we tried lowering the debugging bus speed to 100k or so, but only got limited results. At that speed, the device becomes visible and connectable, but communication doesn't really work, our software starts to timeout on every message. We also tried to lift the RF trace to route it through a different path away from the debugging traces, but had no success either.
We're using SDK 15.2 with s132_nrf52_6.1.0_softdevice
Is this a known issue with the nRF? Cound this be an issue on our design? How can we proceed to debug this?
Thanks
Federico
