Is semihosting supported when running on an ST-Link/v2? #1368
-
|
I'm trying to follow the rust book for embedded programming (https://docs.rust-embedded.org/book/start/hardware.html). At some point it tells me to enable semihosting, which restuls in: I'm new to this, so I have no clue if it's just not supported, if I compiled the blackmagic firmware wrong, if I compiled my program incorrectly, or screwed up something different entirely. I did see the https://black-magic.org/usage/semihosting.html section on the website, and I assume those flags need to be passed to the linker of my rust program. But I haven't found any way to do that / the rust book I'm reading does not mention this, nor did I find it in the documentation of https://crates.io/crates/cortex-m-semihosting (which implements the semihosting). Help is greatly appreciated 😊. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 10 replies
-
|
The ST-Link v2 platform should support semihosting, so the redirect command should be visible in the You are correct that you do have to compile with an appropriate crate that invokes the semihosting halo using the break instruction that encodes to |
Beta Was this translation helpful? Give feedback.
-
|
@dragonmux Ahh, thank you so much! Yes, I am on Linux and I see the Just a little suggestion from a novice, wouldn't it be helpful if those commands were documented under https://black-magic.org/usage/semihosting.html? Because I thought it might work differently, but didn't find anything in, what I thought was the correct, documentation page. Anyway, I tried attaching to the serial port using Here is the code I'm using: hprintln!(">>>>>>>>>>>>>>>..").unwrap();
let mut led_pin = pins.gpio25.into_push_pull_output();
loop {
led_pin.set_high().unwrap();
hprintln!("high").unwrap();
delay.delay_ms(500);
led_pin.set_low().unwrap();
hprintln!("low").unwrap();
delay.delay_ms(500);
}Output from the second serial interface (with (yes, there is something wrong with the newlines and I'm not good enough to figure it out lol) Output from gdb (without |
Beta Was this translation helpful? Give feedback.
-
|
Okay, here is what I did:
The blackmagic firmware seems to connect, but Reverting to the firmware compiled without debug, seems to restore the old behaviour, where I'm getting: I have the following udev rule setup, in case that is breaking anything...: |
Beta Was this translation helpful? Give feedback.
-
|
The probe also hangs when trying to reconnect to a device that was reset: Again, the LED on the ST-Link is blue (instead of red or blinking when doing something), and the GDP prompt is unresponsive. |
Beta Was this translation helpful? Give feedback.
-
If you were working from a fresh clone or having done
That's as expected, you did the right thing here.
This isn't so good though - this indicates something having gone dreadfully wrong. The USB configuration has to be set before any other part of enumeration (like the CDC ACM interfaces being bound by the driver) can occur at that point. We're interested on what could have gone on here as it's not the first time people have reported issues with ST-Link v2's trying to run debug builds. If you have, for example, a USB analyser this would be a useful thing to get a capture from.
udev rules should not have participated in this. The failure is occurring far too early for them to be involved. We do suggest using the project rules files, but there's nothing particularly wrong with that rule. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, quite a lot of work during the week, so here a late response.
Is a USB analyzer a special piece of hardware that I need to buy, or is that a software? In either case, could you give me some examples or links? If it's not too expensive, I'm willing to get one :) |
Beta Was this translation helpful? Give feedback.
-
|
Turns out that you probably got bitten by the semihosting bugs that have now been fixed in latest |
Beta Was this translation helpful? Give feedback.
-
|
You make a fair point regarding documenting semihosting better. We agree the documentation is lacking and it's on our list of things to fix, if someone doesn't contribute better documentation first. At the moment that page is more focused on how to enable use of semihosting and is C-focused (the library calls talked about are specific to newlib and C family languages). It being rewritten to have sections on making use of semihosting within BMP, how to enable semihosting in C-based firmware and how to enable semihosting in Rust-based firmware at a minimum would probably be ideal and the direction we'd take it when we get around to it. |
Beta Was this translation helpful? Give feedback.
monitor arm semihosting enableis only for OpenOCD. BMP implements a different set of monitor commands (monitor helpto list), and that we remember, semihosting should always be enabled once attached to an ARM core. Semihosting output goes to the secondary serial port for BMP (/dev/ttyBmpTarg if on Linux) when you runmonitor redirect_stdout enable.The ST-Link v2 platform should support semihosting, so the redirect command should be visible in the
monitor helpoutput.You are correct that you do have to compile with an appropriate crate that invokes the semihosting halo using the break instruction that encodes to
0xbeab, but that should be all that is required.