The wolfDemo Board Story: From Idea to Reality

I work building open-source cybersecurity solutions for wolfSSL. These solutions often involve embedded environments, which is why we attended Embedded World in Nuremberg this March. We showcased several embedded security demos running on development boards. It got me thinking: what if we made our own development board?

Concept to reality

The people at wolfSSL, including me, are extremely passionate about what we do. The work often extends into our hobbies. As such, I have already made a port of wolfCrypt to the Commodore Amiga.

At Embedded World, I decided that if we were going to demonstrate our software, we should be doing it on hardware we designed ourselves.

One of the demos was one I had brought along, an STM32MP257-DK running a slide show and wolfCrypt’s benchmark.

Here you can see the development board inside a custom-designed 3D-printed case I made. The case locked in the SD card to prevent removal and blocked access to the buttons. I even used a combined printer-cutter machine to produce the label.

I wasn’t asked to do any of that — I just wanted something that looked good while protecting the buttons and SD card from tampering.

I had some general ideas for what I wanted the wolfSSL development board to be:

• It should use an STM32 microcontroller, at least for the first board, because I’ve designed boards around them before.
• It should have USB-C for power.
• It should have mikroBUS sockets, ideally two of them. This is so that we can easily plug devices such as TPMs.
• It should have the option for using a Tag-Connect cable. This is a personal thing, I love Tag-Connect’s cables and I met the founder at Embedded World. It is a great company.
• It should have the wolfSSL logo and the bark of the wolf should light up.

Before I had even left Embedded World, I had started designing the board. Two weeks later, I had the first revision 0.1 PCBs in my hands.

Revisions

I built a few of them and sent a couple of them off to colleagues. Based on their feedback and some issues I found myself, I made a lot of changes. Most changes were to component positioning, but I also simplified the mikroBUS sockets down to shared SPI, I²C, and UART lines (with separate CS pins). This freed up enough IO for a UART on the USB-C connector which could be used to program the board or just for logging.

This brings us to final version, seen here running a PWM demo with the LEDs.

What is it?

The board is made up of:

• An STM32U585 ARM Cortex-M33 microcontroller. Capable of running at 160 MHz.
• 8 MHz crystal to PLL to 160 MHz, and a 32.768 KHz crystal for the RTC.
• A CH340C USB to serial driver IC connected to UART 1 on the MCU.
• Two mikroBUS sockets for Click Boards.
• Two user programmable buttons.
• A ten-pin ARM programming port (not populated) and six-pin Tag-Connector port for JTAG programming / debugging.
• A USB-C port for power and for UART.
• A BOOT0 switch to flash via the UART.
• Four addressable LED bars made up of inverted cyan LEDs that shine through the PCB substrate.

I then took an SVG of the PCB design and used Tinkercad to make a back plate for it.

Why? Well, partly because I thought it would look good — but also because I’d messed up the transistor wiring for the LEDs in revision 1.0. The backplate neatly hides that patchwork. And finally, it protected the components on the underside. Adding some non-slip pads to the bottom of that board meant that it sat on display stands nicely.

Of course, it wouldn’t be one of my PCBs without at least one easter egg.

What can it do?

Well, one of the primary functions is to run many of the wolfSSL projects. I chose the STM32U585 because it is very capable, 2MB of flash and 768K RAM is buckets of room. Also, this chips has some nice hardware crypto acceleration for AES and SHA-256 which we can use. Here is a wolfCrypt demo connected to the UART.

I then extended this to calculate the heap and stack usage of each algorithm, and finally added a Python script for the PC side which takes the live log lines and converts them into something more presentable.

The ML-KEM results look a little worse here for speed because I optimised the settings for memory usage rather than performance in this benchmark. There are also more algorithms enabled now.

I also have some TPM modules for the mikroBUS sockets to demo wolfTPM — including a custom-designed Click Board for the ST33K TPM.

If you want to find out more, check out the wolfSSL blog about it, which also contains links to the board files and example code. You can also visit us at upcoming expos, where we’ll likely have one on display. I’m manufacturing and distributing them to the wolfSSL engineering team now!