ChibiOS Free Embedded RTOS

We needed a standalone "base" for a project I am working on. In the process, I developed software to clone the stlink functionality using ChibiOS. This plays nicely with openocd. We also built separate command-line and QT applications that use the openocd stlink files to directly access hardware through libusb (not included in the repo) For those that have interest, the source firmware (and an example board design) are here:

https://github.com/geoffreymbrown/iulink

The firmware requires 13K flash in the stm32f042. No crystal is required -- the stm32f042 CRS is supported. Some stlink commands aren't implemented because openocd doesn't use them. The firmware only supports SWD -- not JTAG. It doesn't support SWO trace. It does work with gdb through openocd and flashing our target devices (stm32l432) works well at 32Kbytes/second. If you need high speed, you're better off with the STLINK V3 device. If you need to embed something in a bigger project, this might be a good approach.

Geoffrey Brown

This is very interesting, so you re-implemented ST-Link?

Is there documentation about the commands?

Giovanni

If you consider openocd to be documentation. In a sense, it's reverse engineered from the openocd file: https://github.com/ntfreak/openocd/blob ... link_usb.c

STLink is built on ARM SWD. The SWD protocol is completely documented and there are a number of implementations (black magic probe, daplink, etc.) The STLink protocol is desirable for two reasons -- it's widely supported and it handles block transfers from memory (daplink is really a bit level protocol, black magic probe provides a gdb server interface). The actual STLink protocol turns out to be fairly simple and not all the commands are needed to support openocd which operates at the ARM debug interface level for things like step, halt, etc. Actually, the STLink protocol is somewhat flawed in terms of how it handles error recovery, but there's nothing to be done now.

I'm not sure I would have gone down this path if I'd realized how much work was involved. But now it's done and I think others might be able to use it.

The real use-case is to build a lightweight debug/test/program interface into a hardware system.

We actually use the stlink interface, through a debug handler (part of the Cortex3/4 debug support) with a chibios handler thread to communicate with our tags for configuration and control. We use google protocol buffers as the transport layer for RPC commands. Protocol Buffers ---> slink --> debug interrupt --> chibios thread --> nanopb. That's a whole other story.

Geoffrey

I find this very interesting because it is something I wanted to do but never had time...

For testing purpose my idea was to make some kind of SWD probe but also add some kind of mux to connect multiple board and switch them from remote.

It would be great for batch testing, I waste a lot of time just swapping boards.

Giovanni

Do you know the Black Magic Probe https://github.com/blacksphere/blackmagic?

It runs on lots of different STM32 variants, like the ST link clones, Bluepill boards and so on. It can be adapted to other boards easily. It does not need OpenOCD, it presents a gdb server on an USB-CDC channel. License is GPL.

This is my go-to project when I want to include debugger and flash capability on my own hardware.

I am familiar with black magic probe, but it's a bit "beefy" for my needs and GDB, which I use for debugging, is not a great interface for the other tasks that I care about.

I use openocd only for debugging and flashing. Everything else goes through the stlink interface.

Geoffrey

Giovanni,

I did an earlier version on stm32l432 which also had a virtual com port. Not too challenging to see how that might support a mux function. Happy to share that if it interests you.

Geoffrey

geoffrey.brown wrote:We actually use the stlink interface, through a debug handler (part of the Cortex3/4 debug support) with a chibios handler thread to communicate with our tags for configuration and control. We use google protocol buffers as the transport layer for RPC commands. Protocol Buffers ---> slink --> debug interrupt --> chibios thread --> nanopb. That's a whole other story.

I'm really interested in this part of the story - using protobufs, nanopb, etc ...

Hi Geoffrey,

Please share, I am not sure when I will be able to proceed with my idea but it is nice to be able to start evaluating options.

My dream is some kind of test HW with this mux-able debugger, boards mounted in some kind of mini-rack, and also ports to stimulate SPI, ADC, DAC, CAN etc. This would make HAL tests just a matter of running a script over night. I would be able to test all drivers on all platforms with little effort.

Giovanni

Giovanni,
I've added another directory to the git repository firmware/extensions. This contains the usbcfg.[ch] files I used on boards with a cli. The only additional changes are a shell thread and the ChibiOS serial usb driver and cli. I haven't tried adding this to the stm32f042 and I'm not sure there is enough RAM for the extra thread and usb serial buffers. This is the code I used in an earlier board built with the stm32l432.

Geoffrey