Category Archives: hardware

Minix NEO X5 mini – teardown and serial console

Well, I bought a “Minix NEO X5 mini” for various experiments, eventually planning just a plain linux server, with ethernet and wifi, and a pile more ram and flash than the regular OpenWRT router platforms. I chose this based mostly on the smallest, cheapest that had a physical ethernet port. The other contender was the UG008. (And UG008B) Those are marginally smaller, and have one less fullsize USB, also, I _thought_ I’d read good instructions on getting linux running on the x5mini, but it turned out the instructions were for the x5 (full size) which is very similar, but not the same. I’ve since found instructions for the ug008, maybe I should have bought that. It also has a power button and from the pcb pics, looks like the pads for test points are bigger. No heatsink though, and I’d heard it’s wifi wasn’t as good. (Rumous and hearsay, I’ve no idea really) The second fullsize USB port however, is kinda of interesting. The x5mini came with a rather unusual fullsize USB A male-male cable. And there’s no microusb port for the OTG like normal. Plugging this in to a regular pc host would be disastrous, so the supplied android has a special menu option to enable “connecting to pc” which resets on every boot. If you do have it turned on, and you push the pinhole on the bottom while plugging in the power, you’ll get a usb device that ADB can find. dodgy, a regular OTG port would have been preferable.

So yeah, it works pretty well out of the box, but there’s enough reviews of that. We’re here to pull it apart. The little screws are glued in, so you need a good screwdriver, I almost stripped them getting them out. Then, whee, brown PCB! And whee, they put a weight in it to feel pro ;)

The wifi (rtl8188es) antenna is soldered on, then soldered to an adhesive antenna on the lid, a little awkward, but perfectly reasonable of course. Immediately on the board you can see two missing ICs, one, labelled “WIFI2” is almost certainly Bluetooth, which is not on the x5mini, but is on the x5. More curious though is missing QFP48 IC by the recovery button, and it’s 12 pin “STM_DEBUG” connector. It certainly reminds me of an STM32 footprint, though the debug for cortex-m is normally 10 or 20 pins, not 12? No idea. Two test points on this side, T23 and T24, if it’s indeed a bluetooth module, this is possibly a uart between them? *shrugs*

Back to the “top” side, ethernet is an SMSC LAN8720A, power is a TI T659102, which seems to be pretty common on these boards. There’s two filled jumper blocks with interesting text, “USB1 Device / USB1 Host” and “Auto power on enable/disable” but I’ll leave them for a later time. There’s a rather unexpected battery connector too. Minix doesn’t have any battery backed devices in their catalog, so someone’s design company has been working on this. So much for thinking that minix was an OEM.

T306 is RX, T307 is TX and T308 is GND, for a serial console at 115200, 8N1

minix-neo-x5-mini-pcb-top-notes-30
minix-neo-x5-mini-pcb-bottom-notes-30

Finally, here’s most of the bootup

STM32 Unique ID Register on L1 parts

Last week I mentioned I was seeing duplicate “Unique” ID registers on some STM32L151 parts [1], and included some memory dumps of the three unique ID registers as proof.

However, I had foolishly assumed that on the L1 the Unique ID register was three contiguous 32 bit registers, as it is on the F0, F1, F2, F3 and F4. (The base address changes, but that’s normal and expected)

On the L1, the registers are actually at offset 0, offset 4, and offset 0x14. Thanks for nothing ST! :(
(Oh, and L1 Medium+ and High Density devices use a different base address too, good job)

Here’s some more complete memory dumps for the same three parts I was looking at last week.

UID31:0 UID63:32 UID95:64
Part A 0x0e473233 0x30343433 0x00290031
Part B 0x0e473233 0x30343433 0x00320032
Part C 0x0e473233 0x30343433 0x00380030

Reading other reference manuals, and seeing that the UID registers often have 8 bits of unsigned “Wafer number”, 7 bytes of ASCII Lot number, and 4 bytes of X/Y wafer coordinates in BCD, I would interpret my part “A” above as

Wafer Number Lot Number X/Y coords
Hex 0x0e 0x47323330343433 0x00290031
Natural 0x0e G230443 X=0029, Y=0031

For reference, here are some full dumps of that section of memory. “0x7b747800” is what I had been looking at as UID bits 95:64, note that there are other bits in this section with fixed values, no idea what they mean :)

Part A

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00290031  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x029f067e  0x035a0000
0x1ff80080: 0x035a0000  0x035a0000  0x035a0000  0x035a0000
0x1ff80090: 0x035a0000  0x035a0000  0x035a0000  0x035a0000
(gdb) 

Part B

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00320032  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x02a50685  0x035e0000
0x1ff80080: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
0x1ff80090: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
(gdb)

Part C

(gdb) x /20x 0x1FF80050
0x1ff80050: 0x0e473233  0x30343433  0x7b747800  0x50505091
0x1ff80060: 0x00000011  0x00380030  0x11000000  0x11000011
0x1ff80070: 0x00000000  0x00000000  0x02a50689  0x035e0000
0x1ff80080: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
0x1ff80090: 0x035e0000  0x035e0000  0x035e0000  0x035e0000
(gdb)

[1] Again, these are STM32L151C6T6 parts, revision V, package markings “GH254 VG” and “CHN309”

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

Downloads

Parts list below.

Part

quantity

price

supplier

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

1

7.99 US

ebay

grounded euro socket

1

195 ISK

Byko

grounded euro plug

1

195 ISK

Byko

Ungrounded euro socket

1

181 ISK

Byko

3 strand power cable

2m

363 ISK

Byko

lunch box

1

499 ISK

Húsasmiðjan

Green LED

1

0.05€

Mouser

ATtiny84

1

2.39€

Mouser

MRF24J40MA

1 (optional)

7.46€

Mouser

3.5mm stereo socket, board mount

1

0.44€

Mouser

MCP1702, 3.3V regulator

1

0.39€€

Mouser

TMP36

1

1.58 US

Digikey

1uF capacitors

2

0.40€

Mouser

5V DC plugpack/wallwart

1

500 ISK

Second hand store

2×3 pin header for AVR programming

1

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.