I have a custom board using the u-blox BMD-350 (Nordic nRF52382) chipset (as well as the u-blox development board, the problem occurs on both). I'm using Nordic's Connect SDK version 1.9.0 which uses Zephyr RTOS version v2.7.99-ncs1. Development environment and debugger is Visual Studio Code with nRF Connect extensions.
I can connect with a debugger via SWD and I can monitor things using either Segger RTT logging output or the Bluetooth telemetry it's transmitting. I'm running into a particularly difficult problem to debug, where at startup and for the first couple of seconds things are running smoothly (meaning I'm seeing Bluetooth telemetry come in at the expected rate), but then the device seems to crash and stops outputting Bluetooth telemetry. However, this does not happen if I'm connected with the debugger, and it also typically doesn't happen (or at least not very quickly) when I'm connected via RTT. When I connect to RTT after a crash, I don't really see any helpful feedback, just that the logging has stoped (often midway through a message). Of note, it also doesn't seem to crash unless there is a Bluetooth client connected. The Nordic NUS service is being used almost exactly as it is in the demo, except that the device is configured as a peripheral.
Since I'm not able to get a crash to happen in a debug session, I'm at a bit of a loss how to debug this issue. It doesn't seem to be generating a core dump or a usable error as far as I can see (I have the appropriate flags specified), so I wonder if there is a weird locking condition that's hosing the system (but only outside of the debugger or an active RTT session).
Any thoughts as to how one might go about debugging a bug like this?
You can ozone for debug , kind of better debugger compared to VSCode debugger .Anyway it will also add automatically to VSCode once installed like this. VScode with Ozone