“无法停止 Cortex-M 设备”尝试调试STM32F205ZG时出错

发布于 2025-01-07 10:27:36 字数 118 浏览 7 评论 0原文

我在使用 µVision4 和 ULINK2 的 STM32F205ZG 上运行调试器时遇到问题。我不断收到错误消息“无法停止 Cortex-M 设备!请检查 JTAG 电缆。”我用的是SW端口。任何对此的帮助将不胜感激。

I am having trouble running the debugger on a STM32F205ZG using µVision4 and the ULINK2. I keep getting the error message "Could not stop Cortex-M device! Please check the JTAG cable." I am using the SW port. Any help with this would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

时间海 2025-01-14 10:27:36

根据我自己的经验,当 ULINK2 在调试会话期间断开连接并重新连接时,或者如果您有一些不受调试器控制的外部硬件作用于您的处理器时,我通常会看到此错误。

如果 ULINK2 在调试过程中断开连接,通常重新给设备上电即可解决问题。

如果您有类似看门狗定时器的东西,在调试过程中尝试重置处理器,那么您必须先禁用看门狗,然后才能启动调试会话。

In my own experience I have usually seen this error when either the ULINK2 is disconnected and reconnected while in the middle of a debug session or if you have some external hardware, outside of the control of the debugger, that is acting on your processor.

If the ULINK2 was disconnected mid-debug, then usually cycling power to your device will fix the problem.

If you have something like a watchdog timer that is trying to reset the processor while you are in the middle of debugging, then you will have to disable the watchdog before you can start a debug session.

笑着哭最痛 2025-01-14 10:27:36

我的 NXP uC 也遇到过同样的问题。

问题是闪存中加载的代码有错误,并且将 CPU 置于繁忙循环中并分支回同一地址,这阻止了调试器访问总线。

如果我将设备置于 ISP 模式,uLink 就会工作,因为它永远不会到达用户代码。

似乎 uLink 在重置后需要很长时间才能停止设备,规范在某处告诉您这一点,因此当 uLink 尝试停止 CPU 时,为时已晚,因为它无法访问总线并锁定。

I've seen the same problem with my NXP uC.

The problem was that the code loaded in flash was faulty and was placing the CPU into a busy loop branching back to the same address, this prevented the debugger accessing the bus.

the uLink worked if I put the device into ISP mode as it never got to the user code.

it seems that uLink takes too long to halt the device after reset, the spec tells you this somewhere, so by the time uLink tries to halt the CPU it is too late as it cannot access the bus and locks up.

猫七 2025-01-14 10:27:36

我在 LPC4337 上遇到这个问题。我尝试了人们谈论的所有解决方案,但唯一对我有用的解决方案是使用较低的处理器时钟,以便 JTAG/SWD 接口可以在处理器执行用户代码过多之前匹配/赶上处理器。就我而言,我将 Keil uVision 5 中的 JTAG/SWD 时钟设置为 10MHz,并将处理器时钟分频器更改为 36MHz。通过这些设置,当我开始调试会话时,它永远不会错过重置时的捕获。

ULink2 会发生这种情况,但 ULINK Pro 和 ULINK Pro-D 支持 JTAG/SWD <= 50MHz。更多比较请参见此链接:
ulink 比较

I had this problem on LPC4337. I tried all the solutions people are talking about but the only one that worked for me was using a lower processor clock so that JTAG/SWD interface can match/catch up with the processor before it is gone too far into executing user code. In my case I set JTAG/SWD clock in Keil uVision 5 to 10MHz and the changes the processor clock divisors to give 36MHz. With these settings, it never missed to capture on reset when I begin a debug session.

This happens for ULink2 but ULINK Pro and ULINK Pro-D support a JTAG/SWD <= 50MHz. See this link for more comparisons:
ulink comparisons

云雾 2025-01-14 10:27:36

此消息还有另一个问题:

我们有相同的错误消息,但问题是 RESET 行的状态错误。

Just an other issue with this message:

We have the same error message, but the problem was the wrong state of the RESET line.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文