一个只能随着调试器独立的撞车撞车的Zephyr RTOS应用程序如何调试？
我有一个使用U-Blox BMD-350（NRF52382）芯片组（以及U-Blox开发委员会的自定义板）。我正在使用Nordic的Connect SDK版本1.9.0，该版本使用Zephyr RTOS版本v2.7.99-NCS1。开发环境和调试器是带有NRF连接扩展名的Visual Studio代码。
我可以通过SWD与调试器连接，并且可以使用Segger RTT日志输出或传输的蓝牙遥测来监视事物。我遇到了一个特别困难的问题，在启动和前几秒钟，情况正常运行（这意味着我看到蓝牙遥测以预期的速度出现），但是随后该设备似乎崩溃了，并且停止输出蓝牙遥测。但是，如果我与调试器联系在一起，这不会发生，并且当我通过RTT连接时，通常也不会发生（或至少不是很快）。当我在崩溃后连接到RTT时，我真的没有看到任何有用的反馈，只是登录已经停止（通常是在消息中途）。值得注意的是，除非连接蓝牙客户端，否则它似乎也不会崩溃。 Nordic NUS服务几乎与 demo ，除了设备被配置为外围。
由于我无法在调试会话中发生崩溃，因此我有点损失如何调试此问题。据我所知，它似乎并没有生成核心转储或可用错误（我指定了适当的标志），所以我想知道是否有一个怪异的锁定条件（但是只有在该系统之外调试器或活动RTT会话）。
关于如何调试这样的错误，有什么想法吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以进行臭氧进行调试，与VSCODE调试器相比，它可以更好地调试器。
带有臭氧
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