为什么我通过SWD失去与BlueNRG-2的通信？

如果接口引脚关闭或内部逻辑关闭，您将失去连接。调试时可能有助于设置DBGMCU位，并阻止代码进入某些低功耗和睡眠模式。 WFI的行为也可以定义为在等待下一个中断时关闭。
有很多方法可以调试，除了需要单步执行一切以查看它是如何工作的，考虑使用USART输出状态和遥测，转储寄存器，这样你就可以看到系统在没有连接调试器的情况下的行为（它们通常是系统如何遍历电源状态，重置等以及代码如何流动并与事物交互。



以下为原文




If the interface pins turn off or the internal logic shuts down you will lose connectivity. When debugging it might help to set DBGMCU bits, and stop the code from going into some of the low power and sleep modes. The behaviour of WFI can also be defined to turn things off when waiting for the next interrupt.
There are many ways to debug things, beyond the need to single step everything to see how it works, consider using a USART to output state and telemetry, dump registers, so you can see how the system behaves without a debugger attached (they are often invasive) and how the system traverses power states, resets, etc and how your code flows and interacts with things.

我宁愿期望即使CPU处于WFI状态，ARM Cortex的Debug Cell仍然可以被控制。
 
[更新]：请参阅Cortex-M0文档中的说明。
 
问候，
 
彼得·



以下为原文




I rather expected that Debug Cell of ARM Cortex can be still controlled even if CPU is in WFI state.

[updated]: See description from Cortex-M0 documentation.

Regards,

Piotr

在某些情况下，它不能，这就是重点。



以下为原文




There are situations where it can't and that was the point.

你好
Piotr Romaniuk，
是的，这是因为当BlueNRG-2进入睡眠或待机状态时，调试端口未通电。
有一种解决方法，如数据表3.21.1调试提示中所述
http://www.st.com/resource/en/datasheet/bluenrg-2.pdf
 
 
在某些情况下，禁用调试访问并且无法访问芯片，包括：
 
•禁用调试引脚的应用程序
•将设备设置为睡眠或待机状态的应用程序，其中调试端口未通电。
这些情况在应用程序开发期间很常见，并且设备最终可能处于调试访问状态
不再可能。要恢复这种情况，建议强制IO7引脚高电平并硬件复位
设备，以强制执行更新程序代码（参见第3.23节预编程的引导程序）。用户
然后可以连接SWD接口并擦除器件闪存。
 
最好的祝福，
温弗雷德



以下为原文




Hi
Piotr Romaniuk,

Yes, it is because when BlueNRG-2 entering sleep or standby state, the debug port is not powered.

There is a workaround for this, as described in datasheet 3.21.1 Debugging tips


http://www.st.com/resource/en/datasheet/bluenrg-2.pdf


There are certain situations where debug access is disabled and the chip cannot be accessed, including:

• application that disables debug pins
• application that set the device in sleep or standby state, in which the debug port is not powered.
These cases are common during application development and device can end up in a state where debug access
is no longer possible. To recover this situation, it is recommended to force IO7 pin high and hardware reset the
device in order to force execution of the updater code (see Section 3.23 Pre-programmed bootloader). The user
can then connect with SWD interface and erase the device Flash memory.

Best Regards,
Winfred

＆gt;＆gt; [更新]：请参阅Cortex-M0文档中的说明。
好吧，但是你在体验它不工作，这些都是复杂的设备，并以一些子弹点无法充分捕捉的方式与自己互动。
您要么停止执行某些操作，以便可以按照自己的方式进行调试，或者需要更改调试方式以适应设备的行为。
有时，观察行为会改变测试/实验的结果。



以下为原文




>>[updated]: See description from Cortex-M0 documentation.
Ok, but you're physically experiencing it NOT WORKING, these are complicated devices and interact with themselves in ways that a few bullet-points doesn't adequately capture.
You've either got to stop doing certain things so you can debug in the way you want, or you need to change the way you debug to accommodate the behaviour of the device.
Some times the act of observation alters the outcome of a test/experiment.

嗨克莱夫，
我希望ST-Link设备可能是一个原因。调试器看起来不太专业，并且在工作时出现问题。我想确定是否存在硬件障碍。
我需要一个debuger来检查处理器状态，并尽可能地进行非侵入性操作。我认为通过调试端口与处理器的连接将是这样的方法。醒来时我只是非常卑鄙的问题（
https://community.st.com/0D50X00009Xkht1SAB
 ）。
 
当你提到我时，我会广泛使用其他调试方法。感谢你的评论。
问候，
 
彼得·
 注意：原始帖子包含大量线程对话，只能迁移到第9级



以下为原文




Hi Clive,
I hoped that ST-Link device may be a reason. The debugger does not look very professional and has issues while is working. I wanted to be sure that there is or not hardware obstacle.
I needed a debuger for checking processor state, and doing that as non-invasive as is it possible. I thought that connection to processor by debug port would be such method. I just have very mean issue with waking up (
https://community.st.com/0D50X00009Xkht1SAB
).

I use extensively other methods of debugging as you mention.Thank you for your comments.
Regards,

Piotr
Note: the original post contained a large number of threaded conversations and was only able to be migrated to the 9th level