Conversation

Replying to
My solution up to this point has been a collection of gdbstub bootloaders over USB tied into Erlang system for orchestration. Next iteration is modded black magic probe firmware on blue pill boards. That also runs on those STLink clone boards BTW.
1
1
Replying to
Interesting! This project is specifically a bus with a network, so I've been musing on/avoiding building logging and bootloading capabilities into the bus itself. I do have a stock of black-pill (stm32f4) boards, which I could use as debuggers in a pinch.
1
Replying to
I have proof of concept logging working over SWD. Basically BMP firmware is modded so it polls the uC's log buffer while polling for target halt due to breakpoint. At this point I'm not quite sure if the multiplex is a good idea. First iteration is probably simpler to ...
1
Replying to and
... idea is to do arbitrary messages over SWD. Basically make a dedicated debug/test system that is specific for one application. I hope to finish this as part of my current client project but unclear about timeline. I have a bag of STLinkV2 clones ready!
1
1
Replying to
In general, the probe.rs project has taken a different approach: use off-the-shelf debuggers (STLink, JLink, CMSIS-DAP, etc.), and instead make a host-side library that gives you pretty deep control. It's how we do a TON of the tooling for embedded rust.
1