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
stlink "clone" on stm32f042
-
- Posts: 87
- Joined: Thu May 07, 2015 9:47 pm
- Has thanked: 3 times
- Been thanked: 15 times
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: stlink "clone" on stm32f042
This is very interesting, so you re-implemented ST-Link?
Is there documentation about the commands?
Giovanni
Is there documentation about the commands?
Giovanni
-
- Posts: 87
- Joined: Thu May 07, 2015 9:47 pm
- Has thanked: 3 times
- Been thanked: 15 times
Re: stlink "clone" on stm32f042
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
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
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: stlink "clone" on stm32f042
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
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
-
- Posts: 77
- Joined: Sat Mar 19, 2016 8:07 pm
- Been thanked: 17 times
Re: stlink "clone" on stm32f042
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.
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.
-
- Posts: 87
- Joined: Thu May 07, 2015 9:47 pm
- Has thanked: 3 times
- Been thanked: 15 times
Re: stlink "clone" on stm32f042
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
I use openocd only for debugging and flashing. Everything else goes through the stlink interface.
Geoffrey
-
- Posts: 87
- Joined: Thu May 07, 2015 9:47 pm
- Has thanked: 3 times
- Been thanked: 15 times
Re: stlink "clone" on stm32f042
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
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
Re: stlink "clone" on stm32f042
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 ...
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: stlink "clone" on stm32f042
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
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
-
- Posts: 87
- Joined: Thu May 07, 2015 9:47 pm
- Has thanked: 3 times
- Been thanked: 15 times
Re: stlink "clone" on stm32f042
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
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
Who is online
Users browsing this forum: No registered users and 21 guests