STLink V3-PWR

Posted on April 8, 2023 by David Albert

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)
USB-to-serial converter
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).

Key Strengths

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.

Cost:

$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.

Hardware Limitations:

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 “STC14″ connector. 0.050” (1.27mm) connectors are simply awful, particularly for developers. Many targets won’t have the same STC14 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 STC14 breakout boards from OSHPark (9 PCBs for $11.10 shipped) and mount either these nice but very expensive Samtec connectors (left) or these much cheaper CNC Tech connectors (right).

Software Limitations

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.

Overall, the V3-PWR gets 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.

Competitors

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.

Internet Security

Posted on February 28, 2023 by David Albert

We all know things are ugly out there, but things are particularly ugly in the growing world of connected devices where security is often an afterthought or under-powered for the modern internet.

I was reminded of this yesterday when I needed to recover the root password for an internet device (with the permission of the device’s owner who had forgotten it…so it was legit to hack). Like many such devices, it used a scaled-down older linux kernel, BusyBox, and an old-fashioned /etc/passwd file where salted passwords are stored md5-crypt hashed. (format: $1$<salt>$<128-bithash>.

Fortunately (but also worrying), a popular hacking tool (J ohn the Ripper) makes short easy work of such files. And when I say “easy”, I mean ridiculously easy and when I say “short”, I mean weak passwords are cracked in seconds. If you have access to the passwd file (let’s call it passwd.txt) you would just run the command “john passwd.txt” and in a few minutes, voila: out pop the decrypted passwords. You can enhance JtR with (big) lists of common passwords; there are free lists here and you can also buy lists. You can run JtR on a multi-core machine with a word list using a command like:

john –fork=8 –wordlist=mywordlist.txt filetocrack.txt

In the past, I wouldn’t make a post like this for fear of encouraging hacking, but these days, that fear is misplaced. Tools like JtR (and many much more powerful) are so easy to use and so widely available that *any* hacker at any level knows about them. So rather than keeping head in sand, it’s time to bite the bullet and start assessing (and fixing) your products’ security.

Hire someone to help with security if:
- your system stores plaintext passwords
- your passwords aren’t salted before hashing
- you don’t have a delay before re-entering the password after a few failed attempts
If your products run on small/old linux kernels and/or otherwise use md5crypt for password hashing, consider upgrading and hash passwords using at least SHA256.
Prompt users when they are entering new passwords for what makes a quality password: use an obscure phrase rather than single words or a word with some numbers or some variation on their username.
Store usernames and passwords separately such that only the root user has access to the password file (/etc/passwd and /etc/shadow)
Check new passwords against known lists of pwnd passwords and warn the user.
Run tools like JtR against your own passwd stores and if it quickly guesses your passwords, know that hackers will be doing the same thing.
If possible, don’t use passwords at all on internet-facing systems; use public key certificates instead.
In your own (home/business) networks, segregate insecure devices (i.e. nearly every internet-enabled appliance: cameras, TV streamers, doorbells, etc.) from your computers and storage systems. Devices belong on the guest network or separate VLANs…not on your main WiFi/LAN.
Don’t use the same passwords in internet appliances that you use for things you care about. Assume the internet devices have been cracked. The security in internet appliances is usually *vastly* worse and when hackers crack that doorbell/camera, you don’t want that giving them access to the rest of your network, bank account, etc.
Ideally, use a different, good password for every account. Use a free tool like PasswordSafe to keep your passwords secure; encrypt the safe where your passwords are stored with a single very good password that you don’t use anywhere else and then you can store it on the cloud (OneDrive, GoogleDrive, whatever) so you have easy access to your passwords, but hackers don’t.

Raspberry Pi alternatives

Posted on January 8, 2023 by David Albert

Libre ROC-RK3328-CC Single Board Linux Computer

When folks need a small embedded linux machine for control applications, a Raspberry Pi is usually the first thought. I’ve made good use of Raspberry Pi Zeros and 3Bs but have been reluctant to adopt the RPi 4 due to the apparent need for active cooling, high power consumption, very poor availability, and high pricing (it makes little sense to use an RPi when you could use a much more powerful x86-family platform).

With RPis out of stock for months and being scalped everywhere, I decided to try a Libre Computer ROC-RK3328-CC which is footprint/form factor compatible with the Raspberry Pi and can run Ubuntu, Raspberry Pi OS, Armbian, Debian, Android, and many other OS. The docs are here. The board comes in two versions: 2GB for $45 and 4GB for $55 – those prices are with free one-day shipping via amazon prime and they are available immediately. I bought the 4GB version which is 4x the memory of an RPi 3B+; the memory is also DDR4 vs. the DDR3 used on the Pi. The board is easily passively cooled; I bought the custom heat sink ($10) although any similarly sized heatsink should work fine.

I tried Ubuntu desktop but was disappointed by the bloat and installed Raspberry Pi OS (a Debian derivative) instead and am very happy with it; I installed the desktop (not lite) version. The board is DIN-rail mounted using this high-quality mounting solution. It runs several minicom sessions monitoring/logging other embedded boards as well as a Postgres database and Java backend data collection application. Even over TightVNC, it feels snappy and doesn’t break a sweat (stays between 45 and 47C); it is using less than 1/4 of the available RAM (but would have used nearly all of the RAM on an RPi3).

Other upsides: 4K video (mainly of value for HTPC applications) and USB 3.0 – much more important because it makes it worthwhile to connect an external SSD which will be much faster and more reliable than uSD storage. The main downsides relative to the Raspberry Pi are: no WiFi/Bluetooth and no Pi-compatible camera connector. I didn’t need those for my application (which is rack-mounted and connected to Ethernet), but if you need either, you can easily solve them via USB connection.

For storage, I use Sandisk Extreme uSD cards. 64GB costs $11 and is plenty of storage for my application (I’m only using 6%); if I need more, storage or speed, I’ll use an external M.2 card connected via USB 3.0. Note: there is a huge difference in performance and reliability between SD storage cards used in RPi applications; some cards won’t work at all, some will work but at half the speed of others (see this performance comparison). I’ve tried a bunch and settled on the Sandisk Extreme which offer good speed with a cost only slightly higher than lesser cards; the benchmarks bear this out. If I were doing something more disk-intensive, I’d consider either a board with a native M.2 interface (like the Odroid M1) or an x86 board with a native SATA or M.2 interface.

Note: uSD cards aren’t meant for frequent writing (as in linux logs), so if you want your card to last, I strongly recommend using a utility like log2ram that creates a small RAM disk for the /var/log partition (you can add others) and then periodically flushes that partition to SD storage. This will dramatically lengthen the life of your SD card; see here for more info.