Category Archives: hardware

STM32 Unique ID register not so unique (Or, how to read docs properly)

UPDATE: This post is WRONG! See updated information here

The findings below were based on expecting the UID register to be contiguous as it is on all other STM32 parts. This is not true on the L1 family, and I hadn’t taken enough care with reading the reference manual.

Original post below

Following up from when I wrote about it earlier, it turns out that the “unique” id isn’t as unique as it is meant to be.

On my desk I have three different STM32L151C6T6 revision “V” parts, with exactly the same 96bit unique id. The parts all have package labels “GH254 VG” and CHN309

UID[32:0] (0x1FF80050) UID[63:32] (0x1FF80054) UID[96:64] (0x1FF80058)
Hex 0x0e473233 0x30343433 0x7b747800
Decimal 239546931 808727603 2071230464

According to reports on the irc channel ##stm32, this has also been seen (at least) on stm32f407vet6 parts.

Not fun :(

ID12 RFID breakout board

Some time ago I got an ID12 RFID reader module from Sparkfun, during their free day. I had some 2mm socket headers lying around from an xbee project, and finally got around to trying this thing out. Sparkfun sells a “breakout”, but in my mind it’s a bit of a failure, as it takes up too much space for easily mounting on a breadboard.

So, I made my own.
ID12 RFID Breadboard friendly breakout

I integrated the LED indicator of a successful read onto the board, and only the useful headers for the ID12 and ID20 modules. It’s much narrower, so easier to use on a breadboard. My board is only ~39mm x 19mm, designed to fit over the channel on a regular breadboard, yet still leave space for plugging wires in. Sparkfun’s is 25mm x 25mm. There’s not much too the design really,

This board was laid out to be made on a milling machine, so there’s no silkscreen text, it’s all in the copper layer instead, and it avoids assuming plated through holes, but it would work just fine manufactured normally. The LED circuit is surface mount, but you can ignore that completely by just not populating those parts.

You can get the eagle files in my github repository

Consider the license to be public domain, or your choice of BSD/MIT/X11.

I’ve only found one RFID card in my wallet that it can actually read, turns out there’s more rfid standards than I thought!

STM32 Device Electronic Signature – Unique Device ID Register

STM32 parts, in all families, have a “Device Electronic Signature” block, which contains a Unique Device ID register of 96 bits. It’s burnt in to the part during manufacture, and is guaranteed to be unique for any device in any context Now, 96 bits is fairly large, and in one application of mine, I need an 8 bit number that reliably varies between devices, and also a 48bit serial number. (Like a MAC address, or EUI48) The canonical way of doing this is to hash the large value to get a small value. I was hoping to use 48 bits of the unique id as “unique enough”

ST doesn’t provide much/any information about what goes into this 96 bit number, but there’s internet rumours that it includes things like wafer x,y position, manufacturing datecodes and so on. If I want something that reliably varies, I need to know a little bit more. I don’t have anything really conclusive, but it looks like I really will have to hash the unique id. Here’s the unique id bits from three STM32F100C8 parts purchased from mouser in the same lot. (Can’t find the order date right now)

device uniqueid[95:64] uniqueid[63:32] uniqueid[31:0]
STM32F100C8-A 0x43023307 0x36314732 0x06E30030
STM32F100C8-B 0x43022507 0x36314732 0x06CF0030
STM32F100C8-C 0x43022407 0x36314732 0x06D10030
STM32F100RB (STM32VL Discovery board) 0x43172128 0x30345532 0x06B30036

On the STM32F0 datasheet, the bits are actually described, and there’s no real reason to assume that it ever changed. They list bits 95:64 as LOT_NUM[55:24], bits 63:40 as LOT_NUM[23:0], bits 39:32 as WAF_NUM[7:0] and bits 31:0 as X and Y coordinates on the wafer expressed in BCD format. That would imply that my three parts in the same box came from the same wafter, but different lot numbers. So, well, maybe it was a different scheme for the F1 :)

Looks like I’ll be hashing anyway then :)

The strange prices of chips at distributors (STM32F100 prices)

A while ago I bought some STM32F100C8 chips (64k flash, 8k sram) because they were cheaper than the F100C6 chips, 32k flash, 4 k sram. At least at the time. I was recently looking at them again, and decided to price chart the whole family of STM32F100Cxxxx, across Digiey, Mouser and Farnell (/Newark/element14 etc)

STM32F100C is the 48pin LQFP package. Results were interesting to say the least. Prices are for 100 units, so not huge scale, but more than just a couple of prototypes. Prices are in USD, and were advertised when I wrote this post.

Points of note

  • Newark/farnell cheaper almost across the board. That’s unusual for us, but we may have to look at them a bit more often now :)
  • DigiKey is the only one where the price actually goes up as you increase the specs. Mouser has the C6 cheaper than the C4, and Newark/Farnell has the CB cheaper than the C8
Part flash ram DigiKey Mouser Newark/Farnell
STM32F100C4 16KB 4KB 1.98 2.11 1.64
STM32F100C6 32KB 4KB 2.091 1.99 1.91
STM32F100C8 64KB 8KB 2.8085 2.93 2.89
STM32F100CB 128KB 8KB 3.239 3.09 2.87

Getting started with ARM Cortex-M3 (STM32L1xxx) programming

So yeah, we fixed the linux development and programming tools for the STM32 series of ARM cortex M3 chips. And I spent quite a few weeks getting distracted by the tools, and never got around to actually developing for the platform.

Today I sat down to try and wire up a Microchip MRF24J40MA 802.15.4 module to the STM32L discovery board. Seemed straight forward enough, “what pins are for SPI”

“…..” What the… These pins could be anywhere! The reference manual doesn’t say, it refers to the datasheet, which has a table, “Table 5, Alternate function input/output” on page 35 of the actual device datasheet, revision 4. That table says that there are two SPI ports, and they can be made available on a variety of pins. Apparently, SPI1 and SPI2 can be made available on two separate sets of pins each!

All well and good, but how? That’s for another day :)

Solving the STM32 MCU datasheet maze

I’ve been hacking a lot on STM32 based microcontrollers recently. Not on any particularly useful code, but trying to make the support for the STLink v1 and STLink v2 SWD debuggers built into the various Discovery boards that ST makes really rock solid. It’s a bit of a battle, but it’s coming along

One of the things that has been causing some problems is the sheer volume of information spread across all the different datasheets and release notes. This is going to be particularly apparent as I try to fix the flash programming. Anyway, this afternoon I mapped out the relations between all the datasheets, and put them in a table that I think should help…. (This is based on latest datasheets as of today, some of the numbers changed recently)

The very very very rough version of the map is available here The html is disgusting, blame open office. The spreadsheet it came from is here too:
STM32 Datasheet map

STM32L Discovery Board – first impressions

I’ve been increasingly intrigued by the plummeting price of ARM cortex-M3 devices, both the chips themselves, and also some of the development boards. With ST’s newest, the low power STM32L Discovery board, I thought I’d take the plunge, see what could be done. For a few dollars more than the STM32VL Discovery board, you get:

  • Twice the RAM
  • Lower power consumption
  • A touch slider interface
  • A nice glass LCD

I only got it today, and given that I run linux at home, it’s a bit of a minefield of toolchains, especially if I want to use neat things like hardware debugging. (One of the sexy things you get when you move up to a “real” CPU) I’m sure I’ll write more as this unfolds slowly, but here’s some first impressions.

The touch slider is neat! The preloaded demo code cycles through a few different modes showing off lower power consumption, but that sort of stuff you could read off the spec sheet. A nice responsive touch slider and a good clear LCD, with a couple of user LEDs and another hard button (The slider can also be used as 4 buttons) makes this a pretty kick arse basic platform!

The screen printing is a bit messy and cluttered, with lots of different sizes. I really don’t know why they felt they need to print the numbers of every resistor and capacitor? It’s a little hard to find which jumper is which. Continuing on cosmetics, why are some jumpers labelled JP, and some labelled CN? Why are some of them on the bottom of the board, and some on top? Odd. Anyway, let’s see if we can get some code on it!

Fridge Controller – temperature and motor run time, reporting over 802.15.4

One of my most finished projects, mostly because it’s simply much more important than having a battery powered thermometer sitting on a shelf. I brew beer, and serve beer in a converted fridge in my loungeroom. One day, the beer got slow, and what came out was suspicously cold. Turns out the thermostat was broken, so as long as the fridge had power, it was cooling, which resulted in deeply frozen kegs of beer.

It’s a pretty old fridge, that I got free, so I thought about simply getting a new (second hand) fridge and doing the conversion again. A newer fridge would probably be quieter, use less energy, all good things. But, not all fridges are the same shape, and finding one that fit three kegs, and doing all the work of the conversion again just felt like a lot of work. And goddamnit, I’ve been building sensor nodes, I always planned on having nodes that could control things too, so maybe I should just get down to business.

In the end there wasn’t much too it. I’m not doing any fancy PID control, just a set point, and a minimum motor run time, and minimum motor rest time. Initially, it didn’t even listen to any controls from my network, it reported temperature and motor status, but that was it. I had no beer! This was too important to have offline for weeks while I played around 24-480

I got a (massivly overspecced) 25A SSR on ebay, and after a bit of thought about how to keep the cost down, came up with the following schematic:

Full schematic for the fridge controller

The clever bit, if I can call it that, was to not even think about making my own power supply for the control logic. Big companies can make 10 gazillion CE marked, compact, safe switch mode power supplies, and consumers can throw them out by the gazillion. I was just going to have a normal euro 2 prong socket, and a surplus phone charger plug pack with the jack cut off and soldered to the board. Presto, cheap _and_ safe. Far far cheaper, faster and easier than I could have done myself. Of course, the extra socket and jacks take up space, but you can only have so much cake.

There’s really not an awful lot more to it than that. I tested this with a teensy board first, because I could use the nice friendly USB port for debugging, then switched to the ATtiny84, and after a bit of fiddling to get USI working for SPI, it all “just worked” I was suitably impressed when the fridge turned on and off at the right times :)

If you want to make this cheaper, you can just drop the 802.15.4 radio altogether. It worked well enough to keep my beer cold but not frozen before I finished the code to listen for new parameters over the air. But, being able to tweak it’s settings is a nice thing.

The TMP36, or similar, is wired up on a chopped up length of headphone cable. This is the bit that’s easiest to get wrong. Take care with the pinouts of whatever headphone socket you use, and the way you wire which lead to which part of the 3.5mm stereo plug. (If you get it wrong, you’ll read temperatures like 50, then 80, then 90 degrees Celsius, which will actually be _correct_ if you touch the sensor!)

Things I would have liked to have done:

  • Make the headphone socket mount flush on the wall of the box. Just takes more money and time to get the mounting perfect.
  • Use a panel mount socket for both input and output. It would be much tidier, but it takes yet more space, and yet again, more money

Other notes

The SSR I got really needs 3V+ to control. I was mistakenly feeding it with about 2V, from the wrong side of a resistor divider, early on in testing, and the red LED on the device would light up, so I expected it to properly be switching the live side. However, it seems 2V was enough for the LED, but not enough to actually switch. As soon as I gave it 3V, it behaved perfectly.

There’s no LCD display. Which might have been nice, but really, how often do you look at the temperature of your fridge? Besides, because it’s reporting every 10 seconds to “karlnet” it becomes just another node that the rest of my system stores in databases, graphs, or uploads to pachube

The software has a fairly nice way of working with saved state in EEPROM I learnt recently. I’m quite happy with it :) However, in general, the code is a little bit harder to read, because it contains all the debug for a teensy board, with #defines separating the live code from the test code. This is however a fully fledged real demo of my updated MRF24J40 library code


Parts list below.





25A SSR, 3-25V control, 24-480VAC output


7.99 US


grounded euro socket


195 ISK


grounded euro plug


195 ISK


Ungrounded euro socket


181 ISK


3 strand power cable


363 ISK


lunch box


499 ISK


Green LED









1 (optional)



3.5mm stereo socket, board mount




MCP1702, 3.3V regulator






1.58 US


1uF capacitors




5V DC plugpack/wallwart


500 ISK

Second hand store

2×3 pin header for AVR programming


sockets and header pins to comfort




The mouser parts should be available as Shared project 3411228a84 You can substitute something else for the TMP36, that’s just what I had wired up.

Because remember, Digikey are evil, and still refuse to recognise that the 802.15.4 encryption was removed from export restrictions years ago. Digikey, in their infinite wisdom REFUSE TO SHIP 802.15.4 modules to Iceland. We’re terrorists or something.

Remember, chip select pins need to be outputs!

I was struggling with (very) unreliable file reads and writes while trying to get FatFs running on an Arduino Mega 2560 board, with the standard Arduino Ethernet Shield. The ethernet connection was continually dropping and reconnecting as well.

What was missing? I hadn’t set the pin used for chip select on the SD card to be an output. As soon as I added that, my file operations became 100% reliable, and my ethernet connection stopped bouncing. Excellent!

(I’ll try and package up what we needed to get FatFs working, but it might not be today)

Dresden Elektronik ATmega128RFA1 breakout boards, deRFmega128

I’ll write up more about the parts themselves later, but I finally got boards made for Dresden Elektronik’s deRFmega128 modules, both made, and now assembled and tested. Briefly, these are a module with Atmel’s ATmega128RFA1 (a combined ATmega128 with a 802.15.4 2.4 Ghz transceiver on a single chip) with either a chip antenna, or a connector for your own antenna. These are TINY, and they also manage to pack a 1Mbit EEPROM on the module, for your own use. All for 21€

I’ve only tested a basic blinky thing so far, but it’s good to know that I can finally start doing something with these cool modules.

Here’s one up on a breadboard.

These modules are the same length as PJRC’s Teensy boards, but they have leads on 1.27mm pitch, not 2.54mm pitch. Lots more pins, but you’ll need some parts. For the 1.27mm socket holders, I ordered direct from Samtec. [1] Dresden recommends SLM Series, but I ordered SMS series. It may have been price, or availability, who knows. I ordered SMS-123-02-G-S, and the pins are really way too long on those. SMS-01-G-S would have been a better choice. Also, and I don’t know if the SLM would have been better, but I have a little bit of a hard time getting the modules into these sockets. They seem to “spring” out a little bit, to point that I initially thought I had failed to make my pcbs properly. Some of the pins weren’t making good contact. I have my modules mounted “upside down” with the silver RF can facing down. That’s the way the module leads are longest, and gold, and the only way they fit, when I was testing out the sockets and the modules. (Before the boards got here)

I’ve now found, that they will fit in nicely with the metal can UP and click into place nicely, but that’s not pin compatible with the AVR ISP header, or the power supply I put on the breakout.

So, I have some breakouts that work just fine, if you solder the part in, and probably well enough for development before your own boards, but I’m probably going to respin them :( The modules are cool, and they just came out with a pin compatible module, with an ARM7 core, instead of the ATmega128.

I still have a spare board from this revision though, if you are at all interested, I can send you one :)

Here’s the board itself

Note, it already says rev3. That’s a story for another day :)

And to leave you, a picture of the different RF modules I’ve been working with here recently.

deRFmega128, Teensy v2 + MRF24J40MA, Xbee Series 1 + adafruit board

The current board files are available from

The very basic blinking demo is also at github, should you really want it :)

[1] You can pretty much forget about getting 23pin headers from either digikey or mouser. Samtec were prompt, and had cheap enough shipping, relatively speaking. (I ordered a dozen)