0

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?

Anthony
  • 2,256
  • 2
  • 20
  • 36
  • My first question in these situations is, "Are the configurable system faults enabled and do the fault handlers do anything meaningful like store away the fault status registers for later examination?" With reasonable code in the fault handlers then you can determine if the software is operating the processor core properly. – andy mango Apr 21 '22 at 19:20
  • @andymango That's a good point, I'll have to get back to you on that one. I've just started using Zephyr and the Nordic Connect SDK and I'm not yet familiar with the fault handling facilities available. – Anthony Apr 21 '22 at 19:56

1 Answers1

0

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

Ace
  • 1
  • 1