Debugging LPC4088 with VSCode and CMSIS-DAP

Advanced Solutions Debugging
,
7

The DAPLink firmware was already updated to the newest version. But when the flashed configuration is corrupt, it does not allow to reflash with cmsis-dap. Because I new that JLink was able to fix the problem, I did not dig deeper, even if it was annoying.

With JLink, a was able to upload/debug on the first try, but it would be great if the onboard debugger would work as well.

Thanks for the hint with the API call, thats what I missed.

I agree, it seems that multiple LPC chips have that problem. When I narrowed down the reason, I will report it. Until now I have figured out the following:

  • Setting pyOCD 0.8.0 for tool-pyocd fails (uplod/debug) because platformio uses Python3 and v 0.8.0 is incompatible mainly because of using relative module imports.

  • Setting newer pyOCD for tool-pyocd can successfully upload with upload_protocol = cmsis-dap but fails to debug with pyocd.core.exceptions.TransferError: No ACK received from my initial post.

  • I tried forcing platformio to use python2, but could not get it to work… unsure why

  • The next experiment was a custom debug tool, that points to pyOCD 0.8.0 using python2 while platformio itself uses python3. Fails, I suspect mixing python3 and python2 is not the best idea…

    // upload sucessfully  finished
========================= [SUCCESS] Took 53.37 seconds =========================
undefined  File "C:\Users\chris\.platformio\python3\lib\site.py", line 177
  file=sys.stderr)
      ^
SyntaxError: invalid syntax
Reading symbols from 
c:\Users\chris\OneDrive\Dokumente\PlatformIO\Projects\test_lpc4088\.pio\build\lpc4088\firmware.elf...
C:\Users\chris\.platformio\packages\toolchain-gccarmnoneeabi\bin\arm-none-eabi-gdb.exe: warning: 
Couldn't determine a path for the index cache directory.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = custom
PlatformIO: Initializing remote target...
.pioinit:13: Error in sourced command file:
:3333: No connection could be made because the target machine actively refused it.

  • Somewhere I read that an external gdbserver is used when it is already running. I started (the python2 version) pyocd-gdbserver.exe -t lpc4088 and then starting debugging. This finally succeeded, although the breakpoints were mostly off-by-one… but at least it works.

I will now try to narrow down the pyOCD issue, and try to provide a fix. It might take me a while because it has not the highest priority for me. I will update this thread as soon as I have a better solution.

Thanks for the support and the hints :slight_smile: