我目前在使用 RT1050 时遇到一个问题，我尝试在某个 FreeRTOS 任务中设置断点，但是当到达断点时，调试器无法自行暂停，而是在我之后尝试手动暂停调试器时弹出一个对话框，提示“中断失败”。
我的应用程序启动正常。如果我手动暂停程序，就能获得有效的调试器上下文：
这正是我想要执行的任务，所以我在消息队列接收调用返回后的 switch() 语句处设置了一个断点。我在 NetIfInit() 方法中也设置了第二个断点，就在下面；我希望调试器能够命中这两个断点，或者至少命中其中一个。
我还在测试函数中设置了一个断点，该断点将启动消息队列发送。当我按下串口控制台上的按键时，调试器会到达该断点并停止运行。
然后我进入 NetInit() 函数，该函数最终会调用 xQueueSend()，经过一段漫长的停顿后，调试器会进入该函数。然后我逐步执行 xQueueGenericSend() 函数体，直到执行到这里：
当我尝试单步执行第 846 行时，调试器会暂停一段时间，然后失去上下文。请注意，我的“全部恢复”、“全部暂停”、“全部终止”按钮以及左侧的线程列表都消失了。本次会话仅提供“暂停”和“终止”按钮。如果我点击“暂停”，IDE 会停顿几秒钟，然后弹出以下对话框：
就这样，调试器的工作结束了。与此同时，我的串口控制台卡住了，只显示了一些未写入的 UART 输出。你可能会想，糟了，我把钱都花光了，目标肯定完蛋了……不，并非如此。剩下的唯一按钮是红色的“终止（停止）”按钮，如果我点击它，调试会话就会终止，执行就会恢复……我的任务一切正常。
Initialize eth0.
#DA4 12.996 | eth: netif init
#DA4 12.999 | eth: NV MAC = 00-07-F0-00-56-03
#DA4 12.999 | eth: NV cfg: address = 192.168.1.180, netmask = 255.255.252.0, gateway = 192.168.1.1, static
#DA4 13.000 | eth: netif add: MAC 00-07-F0-00-56-03, PHY address 3
Returning to main menu.
#BB4 17.572 | No Handle Base Curr HiWByte State Name
#BB4 17.575 | 10 80010db8 19 19 824 Blocked Tmr Svc
#BB4 17.575 | 05 20206b68 12 12 1396 Suspended led_act
#BB4 17.576 | 04 20206500 12 12 1388 Blocked led_cpu
#BB4 17.576 | 08 2020ba18 8 8 7216 Blocked tcpip_thread
#BB4 17.576 | 07 20209868 7 7 6900 Blocked eth_mgr
#BB4 17.577 | 06 20207818 4 4 1912 Blocked gui
#BB4 17.577 | 01 20203538 3 3 2812 Suspended debug_mgr
#BB4 17.577 | 02 20204a68 2 2 4248 Running test
#BB4 17.577 | 03 20205e88 1 1 3948 Blocked backgrnd
#BB4 17.579 | 09 80010d40 0 0 748 Ready IDLE看来程序确实在我设置的断点处停止了，只是调试器出了问题。
有人知道为什么调试器会突然失灵吗？
（编辑：已添加控制台输出附件，以防有用。）
大卫·罗杰斯
我遇到过类似的情况，调试器在 main() 处没有停止，也无法暂停，而是显示“中断失败”。我通过替换工作区目录“.mcuxpressoide_packages_support”解决了我的问题。和“.metadata”我用的是备份文件。
或许可以从另一台电脑的安装系统中获取这些目录。
或许重新导入项目也能解决问题。
我还想知道这个问题最终是否得到了解决。我遇到了完全相同的问题——我使用的是 MCUXpresso (v11.4)，我的 FreeRTOS 应用程序可以正常运行数小时。我可以手动暂停调试器并单步执行代码。但是，我的程序最终会崩溃，调试器（通过 Segger JLink）只会报告“中断失败”——我失去了所有调试功能。
大家好，
我们目前也遇到了同样的问题。
我们想调试一个问题，但是 J-Link 调试器在命中断点后显示“中断失败”。
既然这个帖子最后只提到了寻求支持，那么问题是否已经解决了呢？
此致
大卫
嗨，埃里希，
等等……你们还在用票务系统？我以为恩智浦半导体几年前就关闭了这条支持渠道，当时他们告诉大家去论坛寻求帮助。（当时我并不太高兴，因为我认为这是客户服务水平的下降，即“不要来找我们，去向公众寻求帮助”。）不过，恩智浦的工程师们似乎很积极地参与论坛讨论，而且通常来说，获得第三方意见是很有帮助的。）
请问是否有提交支持工单的快捷链接？如果我这周能抽出点时间（哈哈），我会看看能不能把我的项目整理成一个版本，至少在 EVKB 上能正常运行，并且仍然能重现断点失败的问题。谢谢。
大卫·R.
嗨，大卫，
您可以通过提交常规支持工单的方式来提交您的项目。我认为如果能在 EVK 上运行，对 IDE 工程师来说只有好处，因为他们有这种硬件可用，而且项目越小越好。
感谢您的帮助！
埃里希
我目前还有很多其他事情要处理，但我会在接下来的几天里尽量给你提供一些额外的信息。你说得对，我肯定不会把我的项目发布到论坛上，但如果你有一个秘密渠道，让我可以直接把我的项目发送给你或者恩智浦的工程师，那我就没问题了。是的，就目前项目的形式而言，它是 100% 可复现的。所以，如果可以的话，请私下把我的项目发给你，这样我就可以尝试做一个修改版本，让它能在 EVKB 上运行，并且仍然能重现这个问题。
大卫·R.
嗨，大卫，
我偶尔也会遇到这种情况，但始终无法重现该问题，而且我猜你也无法分享你的项目（否则：请务必分享）。
我注意到或认为这可能是 SEGGER FreeRTOS 感知实现中的一个问题：我注意到它进行了大量数据读取，导致视图频繁刷新。针对此事，SEGGER 方面已收到待处理的工单。
禁用调试器中的 SEGGER FreeRTOS 感知功能确实很有帮助（但我承认，这使得调试 FreeRTOS 应用程序变得不太方便）。
我做的另一件事是尽可能关闭更多视图（尤其是反汇编视图），以减少流量。
我知道这并不理想，如果您能为 IDE 工程团队提供其他任何信息，那就太好了。
或许 GDB 跟踪信息会有所帮助，请参阅“Eclipse 中的板级启动技巧、GDB 日志和跟踪信息 | MCU on Eclipse”一文。
希望这能帮到您，
埃里希