NCS 3.4.x - runners.pyocd “Waiting for a debug probe matching unique ID … to be connected” error

[zpm1066]

Problem
When attempting to flash a nRF board that uses pyocd as the runner (defined in devices’s baord.cmake) for flashing, the following error occurs.

It doesn’t matter if the external probe is a nrf5xx-dk or a Segger probe.

“pyocd” sees the debug probe correctly.

However, the board can be flashed directly from a nRF Connect session using “west flash -r pyocd”. 

The following shows flashing of sample “Blinky” for board “particle_xenon”.

There is a workaround but it requires a change to the board’s “board.cmake”. We shouldn’t have to change a board’s board.cmake in the Zephyr repo.
This issue exists in NCS 3.4.x and 3.x.x and appears to be a bug in “runners.pyocd”.

Also, tried upgrading “pyocd” to the latest version 0.45.1, as NCS 3.4.1 ships with version 0.42. This change didn’t make any difference.

Workaround
The issue has a workaround by changing the order of the runners in board.cmake.

For example, by making one of the other runners in “boards/particle/xenon/board.cmake” the default (first runner in the list)

board_runner_args(pyocd "--target=nrf52840" "--frequency=4000000")
board_runner_args(nrfjprog "--softreset")
board_runner_args(jlink "--device=nRF52840_xxAA" "--speed=4000")
include(${ZEPHYR_BASE}/boards/common/jlink.board.cmake)
include(${ZEPHYR_BASE}/boards/common/pyocd.board.cmake)
include(${ZEPHYR_BASE}/boards/common/nrfutil.board.cmake)
include(${ZEPHYR_BASE}/boards/common/nrfjprog.board.cmake)

Afterwards, selecting “Flash” from nRF Connect works as per normal.

[Vidar Berg]

Hello,

I was able to replicate the issue, but changing the order in the board.cmake file did not make any difference for me. There seem to be two separate problems: the first is in pyOCD/pylink, which appears to have been addressed already (https://github.com/pyocd/pyOCD/pull/1927) and can be fixed by upgrading the pyOCD version currently included in the toolchain as you did. The second is that the VS Code extension passes the serial number to the flash command with the leading zeros (00xx…) as reported by the jlink driver while pyOCD removes them: https://github.com/pyocd/pyOCD/blob/d1974ffdd16369148ba678478fa85886282d09b1/pyocd/probe/jlink_probe.py#L70.  I'm  not sure if this should fixed in the pyocd runner or in pyocd itself. I guess a simple workaround would be to patch the pyocd so it removes any leading zeroes before passing the serial to the pyocd.

Please note that we do not have official support or test coverage for pyocd. Since you already have a Jlink probe I would recommend you use the nrfutil or jlink runner if possible. You may also consider reporting this issue in the pyocd repo or zephyr upstream to allow the maintainers to review the issue.

Best regards,

Vidar

possible workaround/fix:

diff --git a/scripts/west_commands/runners/pyocd.py b/scripts/west_commands/runners/pyocd.py
index f0075036749..4668520541c 100644
--- a/scripts/west_commands/runners/pyocd.py
+++ b/scripts/west_commands/runners/pyocd.py
@@ -53,7 +53,9 @@ class PyOcdBinaryRunner(ZephyrBinaryRunner):

board_args = []
if dev_id is not None:
- board_args = ['-u', dev_id]
+ board_args = ['-u', dev_id.lstrip('0') or dev_id]
self.board_args = board_args

daparg_args = []

[zpm1066]

Hi Vidar,
How are you doing? Hopefully enjoying the early Fall season.

Thank you for picking up other ticket.

It's little odd that changing the order in the board.cmake didn't resolve the issue for you. It works consistently for me for all the other runners in the list. I'm running NCS 3.4.1 and pyocd 0.45.1.

With your proposed fix,  I'm able to flash the nrf52840 board successfully from VS Code extension. For nRF devices, I do prefer to use nrfutil as the runner. Thank you.

Also, without your fix, I'm able to use "west flash -r pyocd" to flash successfully from the nRF Connect command line and also from the macOS terminal window when using vanilla Zephyr but not from VS Code extension.

Has the VS Code extension always been passing the serial number to the flash command with the leading zeros (00xx…)?  I recall there being an option to select the runner as part of the VS Code extension setting. It's no longer there.

Any how, I'll open an issue in the pyocd repo and also in the zephyr upstream for the maintainers to review the issue.

As always, thank you for your quick response. It's much appreciated.

Kind Regards,
Ravi

[Vidar Berg]

Hi Ravi, 

I'm doing well, thanks for asking, and I hope you are too. I agree it is odd that I didn't see the same result, considering your workaround made it work consistently on your end. I may need to test again to see if missed something. I don't see how the order could matter.

zpm1066 said:

Has the VS Code extension always been passing the serial number to the flash command with the leading zeros (00xx…)?

As far as I know yes. As I understand it, the serial number returned from the Segger libraries have these leading zeroes. 

Kind regards,

Vidar

[zpm1066]

Hi Vidar,

Thank you. I'll close the ticket but will proceed to open up the issue in the pyocd repo and also in the zephyr upstream for their review of your fix.

Kind regards,
Ravi