Intermittent 'DP Wait' error on St boards causes bad state

[thegecko]

OS: MacOS 10.14.5 Mbed OS: 5.13.1 Compiler: GCC or AC6.11 pyOCD: 0.21.0 Targets: ST boards (seen on F411, F413, F042K6, F475IOT)

When deploying or debugging ST targets, occasionally a DP Wait error is thrown. This puts the board into a state which still allows updates via mass storage device but any pyOCD interaction continues to show this error even after a hard reset.

0002309:CRITICAL:__main__:STLink error (20): DP wait
Traceback (most recent call last):
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/__main__.py", line 338, in run
    self._COMMANDS[self._args.cmd](self)
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/__main__.py", line 566, in do_gdbserver
    with session:
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/core/session.py", line 287, in __enter__
    self.open()
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/core/session.py", line 367, in open
    self._board.init()
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/board/board.py", line 83, in init
    self.target.init()
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/core/coresight_target.py", line 158, in init
    seq.invoke()
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/utility/sequencer.py", line 201, in invoke
    resultSequence = call()
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/coresight/dap.py", line 121, in power_up_debug
    self.write_reg(DP_SELECT, 0)
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/coresight/dap.py", line 117, in write_reg
    self.write_dp(addr, data)
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/coresight/dap.py", line 243, in write_dp
    self.link.write_dp(addr, data)
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/stlink_probe.py", line 168, in write_dp
    result = self._link.write_dap_register(STLink.DP_PORT, addr, data)
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/stlink/stlink.py", line 425, in write_dap_register
    self._check_status(response)
  File "/Users/robmor01/mbed-studio-tools/python/lib/python2.7/site-packages/pyocd/probe/stlink/stlink.py", line 292, in _check_status
    raise self._ERROR_CLASSES[status](error_message)
TransferTimeoutError: STLink error (20): DP wait

With reference to https://github.com/mbedmicro/pyOCD/issues/623, the environment isn't in a VM and all firmware is up to date.

It would be good to understand how to recover from this state.

[flit]

Are you using the most recent STLink firmware?

An infinite wait response normally means a stuck transaction. But pyOCD has code to issue an abort, which should recover from this state (and does, in the few cases I've seen).

[thegecko]

Have updated to the latest ST firmware (v34) and can confirm this problem still exists with the F475 IOT board. Updating seemed to resolve the issue on the other boards.

[flit]

Update: I'm now able to reproduce this issue. It requires power cycling the board after programming firmware. The connect_mode=under-reset option on my feature/connect_mode branch allows you to connect successfully. But there are still questions about what's causing the problem that need to be resolved.

[thegecko]

Thanks @flit

[jeromecoutant]

Hi When you connect pyOCD, target is already on I think ?

With latest mbed-os version, target could now is sleep or deep sleep. So I am wondering how pyOCD can sync with target to attach it during a "wake up" ?

@schstm

[flit]

@jeromecoutant You're right that this is related to low power modes. It needs to be addressed in the firmware itself.

There are two options for debug profile builds:

1. The firmware just doesn't go into sleep at all.
2. The firmware writes the DBGMCU_CR bits to enable debug sleep mode when it starts up.

PyOCD does set the DBGMCU_CR bits when it connects. But if the target is already sleeping without these bits set, as happens when you power cycle the board and it starts executing the Mbed OS app, there's nothing PyOCD can do to wake up the device. Support for that has to be integrated into the SoC, primarily by having the DP in an always-on power domain. Unfortunately that is not the case for the vast majority of Cortex-M MCUs. Afaik, only the Arm Musca SoC do this. Aside from adding complexity, the more you put in AON the more leakage you have. There might be some MCU vendors that do this, but I'm not aware of them.

[LMESTM]

Note: mbed-os offers a DEBUG profile that would prevent deep-sleep to be entered and can be used for easy debug.

[flit]

The Debug profile still enters sleep, just not deep sleep. But the debug connection is lost even in sleep, because FCLK is disabled. So you still need to set DBGMCU_CR.DBG_SLEEP, which the STM32 HAL for Mbed OS does not currently do.

[stephwongwt]

Update: I'm now able to reproduce this issue. It requires power cycling the board after programming firmware. The connect_mode=under-reset option on my feature/connect_mode branch allows you to connect successfully. But there are still questions about what's causing the problem that need to be resolved.

@flit I'm having the same issue but I cannot find your linked branch anymore.

[flit]

Closing this issue.

There were two fixes implemented long ago:

• PyOCD was failing to abort a stuck transfer.
• Implemented the connect_mode option, now accessible via --connect/-M on the command line.

If this is still a problem for anyone, please create a new issue.

[jeromecoutant]

Closing this issue.

still opened :-)

[flit]

Oops, thanks @jeromecoutant :)