semihosting on the "blue pill" board

[ldericher]

Hello probe-rs,

I can't seem to get semihosting to work with the "knurling-rs app-template" and my STM32F103C8T6 "blue pill" board. I'm using VSCode and the "Debugger for probe-rs" behind an STLink V2:

$ probe-rs list
The following debug probes were found:
[0]: STLink V2 (VID: 0483, PID: 3748, Serial: [...], StLink)

$ probe-rs info
Probing target via JTAG

ARM Chip:
Debug Port: Version 1, DP Designer: ARM Ltd
└── 0 MemoryAP
    └── ROM Table (Class 1)
        ├── Cortex-M3 SCS   (Generic IP component)
        │   └── CPUID
        │       ├── IMPLEMENTER: ARM Ltd
        │       ├── VARIANT: 1
        │       ├── PARTNO: 3107
        │       └── REVISION: 1
        ├── Cortex-M3 DWT   (Generic IP component)
        ├── Cortex-M3 FBP   (Generic IP component)
        ├── Cortex-M3 ITM   (Generic IP component)
        └── Cortex-M3 TPIU  (Coresight Component)

[...]

Now, whenever I start debugging anything, I end up in line 212 of cortex-m-semihosting/src/lib.rs, indicative of a failed semihosting attempt.

In a more "bare" setup (without knurling-rs, using the "Cortex-Debug" VSC extension and a manually setup "cargo build" prelaunch task) I was able to resolve the same issue leveraging "preLaunchCommands" for the gdb process, i.e. "monitor arm semihosting enable". I can't seem to find a similar setting with the arguably better approach using probe-rs and knurling.

I've selfhosted both experimental projects in my gitea instance and added a containers.dev config for convenience.

• With knurling + probe-rs (failed semihosting): https://code.yavook.de/jmm/bluepill-knurling-rs
• With manual setup + Cortex-Debug: https://code.yavook.de/jmm/bluepill-rust-blinky/src/commit/4132b45631b65d326b8f4ad85acfbc752b64c18a

Any ideas forward?

Crossposted at knurling-rs/app-template/issues/77

[noppej]

The VSCode extension does not have explicit support for semihosting. I believe the CLI interface probe-rs run does have support. PR's are always welcome :)

[ldericher]

I believe the CLI interface probe-rs run does have support.

From my tests, it seems to work as intended: First run uses cortex-m-semihosting = "0.5.0", second run uses cortex-m-semihosting = { version = "0.5.0", features = ["no-semihosting"] }. Notice the extra ^C at the end where I manually stopped execution.

However, with the VSCode extension, debugging just gets stuck at the end of the program:

So yeah, I'd like to use semihosting to automatically terminate the debugging session in the extension as well. Unfortunately, I have zero experience with vscode extension development and my schedule doesn't allow me to get into that right now, so I just hope this could be somewhat easily fixable 😇

[noppej]

Unfortunately, I have zero experience with vscode extension development

For what it is worth, I don't believe there will be any changes required to the VSCode extension. This can be implemented by updating the probe-rs dap server component only, using a similar approach as to that used in the CLI.

[ldericher]

This can be implemented by updating the probe-rs dap server component only

Still not sure where to look next then. probe-rs/dap-rs? probe-rs/probe-rs?

[noppej]

This is the code for the 'master loop' of the debugger, where it synchronizes status of the VSCode/DAP client with that of the target, and executes requests, marshals data, etc. Specifically line 120 will do the poll_cores, and in there, is probably where I would check for semihosting events.

Feel free to check in if you want additional pointers. Always happy to help.

[noppej]

Closing this as NIF until someone is willing to PR this fix :)