Welcome to our second post-campaign update! In this update, we’ll talk about:

• STM32F Socket Board Build
• The CW313 Interposer Build
• Artix A35 Target Design
• Kintex K82F Target Build
• New ChipWhisperer Release

We’ve had only one minor supply chain issue (a suspected fake IC we caught on the CW313), which won’t affect shipping times but is a little interesting to look at in more detail. Let’s dig in!

STM32F Socket Board

One of the campaign pledges was a special socket board designed for STM32F in TQFP64 package. The timing of this board is great, as when you look on Digi-Key for STM32F devices in TQFP64 package you see lots of results in stock:

This wasn’t the case a couple months ago! So if you’ve got some plans to play with STM32F, grab a few of them. For example, you could try recreating the known STM32F1 attack, or take a look at some examples attacking the STM32F205 used in the Trezor device which have been covered by the likes of Joe Grand recovering $2M in crypto, The OG Wallet.Fail Talk, and in a Kraken blogpost. Or take a look at the STM32F3 attack discussed in the paper Shaping the Glitch - we could go on for a while it seems!

Either way - we’ve got a working build of the socket board! It looks like this (shown with a STM32F loaded, not included):

The sockets are from Sensata (Wells-CTI), so they should have good reliability. We purchase the sockets in bulk directly from them, so these aren’t the clone versions you see pop up on AliExpress. We build the boards in-house - there is a small amount of SMD we run ourselves on a desktop pick-n-place:

Following by a reflow oven:

The rest is just through-hole soldered. You might notice the SMD doesn’t have the usual "rails". This was a bit of a rush to get done before Chinese New Year so we ended up forgoing them, knowing that the simple single-sided board would work well enough in our machine.

We’re hoping to get this one out shortly, as it had an earlier delivery date than the rest.

CW313 Interposer Build

In the last update, we mentioned that there was a build of the CW313 interposer occurring. It’s done now, and looks like this:

But on powering it up, something odd happened: the 1.2 V regulator output wasn’t right. Not good! Looking at the board, the 1.2 V regulator looks like this:

This part looked different from the part we had stocked ourselves for the build (and were now just keeping in reserve):

Notice the textured surface and the marks from the mould (little circle upper left)? You can also see that the backs look different. Our part has a moulded origin mark:

Whereas removing the one from the PCB shows this to be missing:

Swapping the suspect one for the real one made the board work again.

Luckily, we already had stock of this part in more than sufficient quantity for the build. We hadn’t sent the parts to our CM as they had listed the part as in-stock, and with their low value ($0.25 each), it simply was more effort to unreel the quantity of the parts and ship them over, than it was to let them buy the exact quantity needed.

We’re not entirely sure if it’s a fake part or we got a defective one by chance? They followed up with the distributor who seemed to have a traceable origin, but we can’t be sure. Either way, they’ll rework the boards with our known good parts, which is a quick process due to the simple rework needed. If timing becomes tight, we might reserve a small number of them to do here, so we can ensure we’re shipping the "earlier" batch of CW-Huskies still.

One final note about the CW313 that is interesting: looking at the board, there isn’t much there - just some headers really. But since we’re specifying name-brand headers, our cost of getting this little interposer board is $52/unit! Part of that is the BOM, dominated by the PCIe style edge connector (PCIE-064-02-F-D-RA, $7.36/each), and the two SMA connectors (2x Molex 73251-1150, $2.1/each). But all the little pin headers add up quickly, especially the labour cost of the through-hole soldering. The board is a 4-layer PCB to give better signal integrity, since you’ll be running clocks and similar through this board.

While there are cheaper off brand versions of the headers and SMA connectors, keeping the exact specified requirements ensures better long-term reliability. We’ve had bad luck using cheaper assembly houses in the past when it comes to the through-hole headers (boards coming back with the headers not perfectly vertical). So even if it seems silly to have such a high cost board, this is part of making sure the experience everyone has with this kit is as frustration-free as we can make it.

Artix A35 Target

Another development is that we have a first prototype of the Artix A35 target (one of the pledges), which was built up today:

We’re still testing it, so far we confirmed it works enough to allow the ChipWhisperer-Husky to download the bitstream. We already use the A35 on the CW305 so have lots of reference material we can quickly make available, including even an Arm DesignStart soft-core!.

You can see the design files already in the open-source repo if you want to follow along. Expect a few more updates on the status of that target shortly. We’d like to port the lowRISC Ibex Core Demos onto this as a ready-to-go soft-core as well.

This target has been delayed because we switched the FPGA package in use. Originally we planned on using the Artix A35 in FTG256 package (1 mm ball spacing on the BGA), which is the same as the CW-Husky. However, when buying parts for this Crowd Supply campaign, we couldn’t find enough availability of the FTG256 package, so we also ordered some of the CSG324 package (which is more pins at 0.8 mm pitch).

To preserve our current XC7A35-1FTG256C stock for the CW-Husky build, we changed the plan for the Artix A35 target to use the CSG324, which is the board you see here now.

Eventually we might respin it to use the XC7A35T-1FTG256C again, since it’s better for us to stock only a single part. We get better pricing by ordering larger quantities of one part, and the FTG256C package is easier to work with, which if people want to build their own target is a nice bonus. Unfortunately, for now we needed to use the CSG324 package to actually get it built!

PS: And if you’re eye is twitching - yes that is none other than a Comic Sans silkscreen font!

Kinetis K82F Target

Part of the hardware pack is the Kinetis K82F, which has lots of interesting cryptographic hardware accelerators. We have a first batch of them in a simple panel we were going to assemble:

On this board, there were two errors: (1) the JTAG VREF pin wasn’t connected, and (2) the default VDD for the internal core logic was using the lower 1.2 V supply (instead of 1.8 V or 3.3 V).

You might wonder why such errors exist when the board is already panelized. This is a bit of a speed optimization we do sometimes - the cost of the actual PCB is so low relative to everything else, we just hope maybe there are no bugs and order it in panel form. If it works out we can jump right to a small run!

In this case, we’ll do another quick spin of these before shipping them. On the plus side, the errors are simple enough that you can still use the boards, as it just needs a couple jumpers on the CW313 mainboard to route the expected power supplies. We can still use them ourselves without issue for development.

We’re still tracking if this means we can deliver the hardware crypto targets in time (given delays due to Chinese New Year & updated PCBs being a couple weeks away). Watch for an update shortly!

New ChipWhisperer Release

Finally - ChipWhisperer 5.7.0 was released last week. It adds a lot of important new features, you’ll notice the majority are for the Husky:

• Automatically setup husky_userio pins for MPSSE when enable_MPSSE() called
• Add SAM4S bootloader support - allows programming SAM4S target boards
• Add SAM4S target HAL
• Add openocd/run_openocd.sh for easier JTAG/SWD programming and debugging
• Add openocd/fe310.cfg to allow fe310 programming via MPSSE

Common build system for capture boards/cw305/cw310

• Add context manager support to ChipWhisperer (thanks @wallento !)
• Add cglitch_setup(), vglitch_setup(), and glitch_disable() to scopes for easy glitch setup/disable.
• Add cw.list_devices() to list attached NewAE devices
• Add scope.reset_clock_phase() for CWNano
• New and improved GlitchController with glitch map support
• Full Husky support for SCA101 and Fault101
• Improve glitch performance on replacement CWNano glitch transistor

We still have some Husky documentation to prepare, but we are happy with the progress towards meeting the ChipWhisperer-Husky goal!