cancel
Showing results for 
Search instead for 
Did you mean: 

StlinkV3 fails to connect to STM32G474 using WFI

Uwe Bonnes
Principal II

Hello,

I have a Nucleo-G474RE with a simple blinker program mostly in WFI, awaking every Millisecond. I can can warm connect with STlinkV2 e.g. by pyOCD, but with on-board StlinkV2 pyOCD reports

Exception reading AP#0 IDR: STLink error (5): No device connected

I can connect when the program does not use WFI.

6 REPLIES 6
Piranha
Chief II

Enable the DBG_SLEEP bit in DBGMCU_CR register.

Uwe Bonnes
Principal II

To enable DBG_SLEEP you need AP access. But as the error above tells, V3 fails to create the AP. So no chance to for any access! B.t.w. you first need to halt the CPU with DHCSR before you can write DBGMCU. But again, writing DHCSR needs AP access.

Piranha
Chief II

Enable it in code for debug builds before any WFI is executed! 🙂 For example, system initialization is a good place.

Uwe Bonnes
Principal II

Other debuggers can attach to the device in that situation. So it is some shortcoming of the StlinkV3.

Piranha
Chief II

For example SEGGER J-Link sets DBG_STANDBY | DBG_STOP|DBG_SLEEP bits before your code can execute WFI. ST-LINK (at least the on-board V2-1) doesn't do that. Apart form waiting on ST for a decades on simple things, another option is to add a debugger script.

# Enable Debug connection in low power modes (DBGMCU->CR)
set 0xE0042004 = (0xE0042004) | 0x7

http://blog.atollic.com/automate-your-gdb-debug-sessions-cortex-m-development

Uwe Bonnes
Principal II

I knowe about those bits. But that changes nothing with the situation that e.g. pyOcd with StlinkV2 _can_ attach, while STLINKV3 does _not_ attach. This is a shortcoming of the StlinkV3 i.m.h.o.