在待机模式下与调试器断开连接断点将在STLINK GDB中保持

如果在程序中的某个位置设置断点，然后通过以下方式使设备进入待机模式：

HAL_PWR_EnterSTANDBYMode();
当调试器仍保持与设备连接（且设备处于待机状态）时，若通过IDE停止调试会话或物理断开SWD连接器终止调试，该断点将在设备唤醒后依然存在。

即使调试器未连接，设备唤醒后仍会在之前设置的断点处停止运行，导致程序挂起。此问题在使用OpenOCD时不会出现。

测试环境：

• 芯片型号：STM32L486JG
• 开发环境：STM32CubeIDE
• 版本：1.6.0
• 构建号：9614_20210223_1703（UTC）
  
  

HAL_GPIO_WritePin(led_red_GPIO_Port, led_red_Pin, GPIO_PIN_SET); HAL_Delay(1000); // Breakpoint here HAL_GPIO_WritePin(led_red_GPIO_Port, led_red_Pin, GPIO_PIN_RESET); HAL_GPIO_WritePin(led_green_GPIO_Port, led_green_Pin, GPIO_PIN_SET); HAL_Delay(1000); HAL_PWR_EnterSTANDBYMode(); // After this one the debugging session is intentionally ended, when the device wakes up it will stop on the first breakpoint and the LED will keep being lit red

这个问题挺坑的，断点信息保存在芯片内部Flash或调试模块里，待机唤醒时没清理。

OpenOCD不会出现这种情况，估计是STLINK调试固件对待机模式处理不完善。

你试过升级STLINK固件吗？有时候新版固件会修复断点残留问题。

也可以试试调试器设置里的“Reset and Halt”功能，唤醒后重置芯片，避免断点残留。

另外，程序进入待机模式前手动清除断点，或用软件复位，可能规避这个问题。

这种断点挂起通常会影响真实运行，建议在生产代码里避免使用待机时断点。

CubeIDE版本比较老了，建议升级到最新版看看问题是否依旧。

如果调试是必须，尝试用SWD重置芯片或者关闭调试后再进入待机。

也有人反馈在断点处加个条件判断，避免唤醒后无限循环断点。

最后建议反馈给ST官方，这类调试器与低功耗模式兼容问题挺常见。