There are three things every STM32 developer wants from a debug dongle:
Power (3v3, 1v8)
So I was excited when ST released their next gen debug interfaces (STLinkV3) and had included support for 1v8 targets and a UART. Was third time a charm? Unfortunately, not. Although the UART and support for lower-voltage targets is a welcome addition, ST made three unfortunate moves with the MINIE that are hard to fathom:
Most notable was their attempt to force use of the STDC14 connector by *only* providing a 0.050 pin header for connections to the target via a fairly fragile connector. It would have been *much* better for it to have a shrouded 2×5 0.100″ pin header (like the “aluminum shell” STLinkV2 clones show below). These would allow use with the ubiquitous Dupont jumper wires that litter every developer’s desk. A tiny PCB with an SMT 2×5 female 0.100 on one side and STDC14 male on the other could have easily adapted to STDC14 when desired, but it’s much harder to go the other direction.
It can’t power the target. Even the sub $3 STLinkV2 clones can power targets at 3v3 and 5v. This is incredibly useful, adds virtually no cost (5V is available from the USB i/f and there’s already a regulator on the STLink for its own uC). An STLink that has SWD, UART, and Power is exactly what every STM32 developer wants…now you need the MINIE and an external power supply!
Finally, there’s the USB-C female connector. Even new laptops have very few USB-C ports (but many USB-A ports); the desktop situation is even worse. The interface itself is only USB 2.0 and the board and can’t supply power to the target, so I can see no rational reason for this choice. I suspect some PLM who has never done any development decided this would be “forward looking”.
The sub-$3 “aluminum shell” STLinkV2 clones nail the mechanical design. They can also power 3v3 and 5V targets. It’s only missing a UART and 1v8 support to be perfect.
So what to do?
You can keep using STLInkV2s, but as designs increasingly move to 1v8, that becomes a problem, requiring a high-speed voltage converter…The STLinkV2 runs an STM32F103 which only runs to 2v0 so you can’t just replace the regulator…and the STLink V2 lacks a UART.
There are adapter boards to convert STLink V3 STC-14 connector to 0.100 pin headers; I covered these in an earlier post discussing the STLink V3-PWR (which does supply power and is a single device solution for most STM32 development/debugging). However, the adapter boards just add another set of wires to clutter your bench and come loose at inopportune times. Fortunately, ST provided an edge connector on the V3MINIE for an imagined board-to-board configuration, and although they spaced the pads at 2mm, you can make them work for a 2.54mm pin header.
The JTAG/SWD pins map to SWD as:
TMS = SWDIO
TDO = SWO (which I rarely use)
It’s easy to solder a 2×5 0.100″ (2.54mm) pin header onto the 2mm pads; just center the middle pin on the middle pad and the other pins are close enough that you can easily make it work.
The soldering here is sloppy, but it shows the concept. The 2×5 pin-header is rock solid when mounted and provides access to all of the pins I use. The UART-side pins (shown to the left) are obvious.
Next time I’ll use a shrouded connector, to prevent accidental contacts and also to have a place to put a small label for each pin (you can’t see the silkscreen for the edge connector contacts when the board is in the 3D-printed enclosure)
ST has also kindly placed an STL file for a 3D-printable case on the product page (under CAD Resources). If you’re using Cura to slice the model, you’ll also need to uncheck the “Union Overlapping Volumes” box in the Mesh Fixes section of the print settings or it will fill in the STDC14 opening. Otherwise, it’s a very nice, compact enclosure with an excellent snap-fit and it holds the PCBA securely.
The original version of the enclosure posted on ST’s product page had the opening for the STDC14 connector slightly shifted and so you had to cut it a bit to make room for the connector. Within a day or so of reporting this to ST (8/2/2023) they had fixed the issue and sent a new STL file to test and it fit perfectly. I expect it will replace the original version shortly.
Figure out how to get the SWD functionality working from the 0.100 header pins
Find a solution for powering the target. If you know of any, please let me know!
ST: if you’re listening, PLEASE give us a nice compact dongle like the V3MINIE but with a USB-A connector, pads for 0.100 pin headers, and 3v3 and 1v8 power outputs.
Update 2023-July: I no longer recommend using this until ST software support improves. At present, there are simply too many issues and it is a frustrating experience. The software seems somewhere between alpha and beta quality: the software that does work has major issues and many important software applications (including from ST) don’t work with it at all (including openocd which works fine with other STLink V3s).
I do a lot of design and development work using STM32 microcontrollers. The low-cost STLinkV2 hardware debug tool is part of what has made these processors so successful: the ability to quickly, inexpensively, and easily flash and debug firmware is a big deal. ST has gone a long way to make life easy for developers and we love them for it!
I have boxes of STLink V2s and clones; I use them all the time. Recently, I’ve started migrating to the STLink V3 and this post covers their most expensive variant: the STLINK V3-PWR which integrates some interesting features including:
SWD debug tool (flashing, debugging target)
variable power source for target (1v6 to 3v6 in 100mV steps)
dynamic current monitoring (100nA to 500mA) with 100ksps (50kHz BW)
It has additional hardware capabilities (SPI, I2C, GPIO, JTAG) that I haven’t tried yet (and it’s not clear that software support for them is ready).
The STLink v3 is fast for flash/debug – even faster than the V2 (which was plenty fast)
The integrated serial interface works perfectly and saves another plug
Nice injection molded enclosure
The variable power source lets me test devices at voltages other than 3v3 and 5v which is more useful than it sounds…it’s often important to understand how the DUT will operate at 1v8.
The ability to monitor dynamic power consumption during development is incredibly useful. I didn’t fully understand this until I started using a Joulescope and realized how much added visibility it provided. I now routinely develop with the DUT powered through a Joulescope so I can better “see” what’s happening. The V3-PWR dynamically switches between 4 current ranges to provide a huge dynamic measurement range without imposing excessive burden voltage.
$95 is crazy expensive for an STLink and serial dongle (V2 clones and serial dongles are individually available for as little as $2 from AliExpress in nice compact aluminum shells).
$95 is crazy cheap for a dynamic power monitor that covers a wide enough current range for IoT development is hard to come by for even a fraction of the price. The Joulescope, is roughly 10x the price (but much more powerful).
If ST make the design public as they did with the V2, we can expect to see the price decline dramatically once Chinese clones appear.
100ksps (50kHz claimed BW) sounds great, but in reality, that sample rate doesn’t provide enough resolution to understand the dynamic power consumption of many IoT devices. It’s super-common for battery-powered devices to wake briefly (uSeconds), do something, and go back to sleep. This is one of the major differences with the Joulescope (2Msps, 300kHz BW).
No pass-through current/power monitoring. Batteries have higher impedance than most line-powered supplies and that impedance varies with temperature and other dynamic feactors (e.g. passivation). The V3-PWR lets you observe the consumption of the DUT, but not its dynamic interaction with a battery. (another difference with the Joulescope).
Power to the DUT is via ~3.5mm screw terminals…not banana jacks, not pluggable screw terminals, not even lever terminals…this was the wrong place to save a few cents.
Connection to the computer *requires* USB-C or the rare USB-A port that supports both data and charging. Maybe this isn’t a big deal or even a limitation, but it’s worth being aware of.
That Dang STC14 connector
The biggest DOH! with the entire STLinkV3 series is ST’s adoption of a 50-mil “STDC14″ connector. 0.050” (1.27mm) connectors are simply awful, particularly for developers. Many targets won’t have the same STDC14 connector and now you can’t use the ubiquitous 100-mil dupont jumpers as we did with STLinkV2. Instead, you need a breakout board to adapt the 0.050 pins to 0.100. You can get inexpensive STDC14 breakout boards from OSHPark (9 PCBs for $11.10 shipped) and mount either these nice but very expensive and somewhat fragile Samtec connectors (left) or these much cheaper and more rugged CNC Tech connectors (right).
No cumulative or average power measurement. This is a huge deal for battery-powered devices (and one that ST can and should add to their software). Understanding average power consumption is key for most battery-powered IoT devices. The sampling limitation might limit accuracy, but this is an easy-to-implement and important missing feature.
The UI is limited (something ST will also hopefully improve over time). It provides a graphical display of current measurement (see below), but is missing features we’ve come to expect from scope-type equipment such as: horizontal or vertical cursors to make and document precise measurements, automatic axis scaling, adjusting the time-base dynamically, etc. ST software developers would be smart to license Joulescope software for the V3-PWR.
When the software associated with the V3-PWR matures, it will get a thumbs up from me. If/when cheaper clones start appearing, I’ll probably have a box of these to replace my STLink V2s. If ST provides an API, these could also form a very useful building block in many factory test fixtures.
Nordic Power Profiler Kit 2 (PPK2) – similar price, wider voltage/current ranges, can measure external current sources (i.e. battery), but no debug/serial functions and no enclosure.
NXP MCU Link Pro – half the cost, but you must select one of two current measurement ranges using a jumper and neither of those ranges fully cover my measurement needs. Within the selected range, the MCULink dynamically switches between 2 sub-ranges, allowing good dynamic range, but not on the level of the other devices. It also has more limited power supply capabilities (two fixed voltages: 1v8, 3v3) and has no enclosure.
I left the monitor running overnight at a high sample rate with acquisition time set to infinite. It turns out that this writes a ton of data to the disk and by morning it had chewed through 160GB of disk space! Even worse, it’s not obvious where the disk space went! So for other users who find this issue, the power acquisition log files are in Users/myUserName/AppData/Local/Temp/Power_Monitor/Acquisition.
ST could significantly improve the software application (STM32CubeMonitor-Power) by adding a few features, some of which seem quite easy:
Checkbox to En/Disable logging (off by default) so you can watch power consumption as you develop/test.
Link to the acquisition logs folder so users can find it easily
Stop/play button so you can pause acquisition to measure an event and then resume
Cumulative power usage counter (so you can confirm expected average power consumption over a long test)
Cursors (current and time) so you can measure and document events
Auto-scale of the Y-axis should adjust to mA when appropriate. A scale from 0..500000uA is just silly and it’s surprisingly annoying to try to distinguish 15000 from 150000.