Bluetooth fail

RE: Bluetooth fail

Hung Bui — Fri, 05 Sep 2025 13:21:20 GMT

Hi,
I don't see how you can use peripheral_uart to scan/search for other Bluetooth device.
The peripheral_uart is peripheral. The way it works is to advertise and wait for connection.
Not sure how step in the code would help in any way here.
You would need to use a phone or another central (central_uart) to connect to it.

If you are not so familiar with Nordic BLE solution, I would suggest to follow this Nordic Academy tutorial:
academy.nordicsemi.com/.../

RE: Bluetooth fail

HHJ — Fri, 05 Sep 2025 01:03:07 GMT

When I open a standard example project located in the directory: nrf\samples\bluetooth\peripheral_uart (the well-known Bluetooth data transparent transmission example), I find that I cannot search for the Bluetooth of my self-developed NRF5340 board. So I start debugging the application core to find what needs to be added (such as prj.conf or dts). The program of the application core often gets stuck in some strange positions. At that time, I guessed whether the network core needed to add something (such as prj.conf or dts), so I started debugging the network core.Could you tell me the answer to the above question? Does the network core not require any handling, including (prj.conf or dts)?

RE: Bluetooth fail

Hung Bui — Thu, 04 Sep 2025 12:48:56 GMT

Hi Hong Hao,
Could you let me know what exactly you want to debug ?
On the nRF53 the netcore mainly contain the BLE controller. If you use Nordic softdevice controller it's not open for debugging. It's provided as a binary library.

In addition, as Jorg already mentioned, when you put a breakpoint, it usually not possible to continue from there as the timing will be messed and you will end up to a fault.

RE: Bluetooth fail

HHJ — Thu, 04 Sep 2025 08:50:09 GMT

Does it mean that the configuration of the network core should not be changed either, and starting from line 11 is my configuration for it?

RE: Bluetooth fail

Turbo J — Thu, 04 Sep 2025 08:39:18 GMT

Don't try to debug the radio processor/network core!

Any stops from the debugger will mess up the BTLE timings which are strongly controlled and will cause the radio core to fault when it can't meet them for any reason.