Getting started with mchck

Note

This describes my work with an older revision (r2) of the MC HCK design. Many things have changed in the last year; the current revision (r5) is built upon a different MCU, the pinout has changed, and the software environment has greatly matured. I’ll try to write about my experiences with this new revision soon. Until then, many of the ideas below still hold true.

The mchck is a small microcontroller development board based around the ARM Cortex M3 intended to be a low-cost (~$5) alternative to the ubiquitous Arduino.

While the design is currently under development, things are quickly stabilizing. Here I describe my experiences sourcing, building, and developing for the mchck.

Parts

I used Seeed Studio’s [Fusion PCB] service to produce the boards. This works quite well as the mchck is nearly exactly half of the area of the smallest board service (5cm x 5cm). Because Seeed allows boards to be panelized, I tiled two boards in my Gerbers, almost perfectly filling the allotted area. While the mchck has contacts intended for use as a USB connector, having the board trimmed to this size would have precluded the use of Seeed and so I instead decided to use a mini-USB B connector.

I’ve found that Future Electronics has very competitive prices but often do not offer many parts (namely passive components). For this reason, I sourced parts from both suppliers. Below is the bill-of-materials. While the cost is certainly above the $5 target, this is to be expected from such a low-volume run.

Construction

Because the microcontroller is the most expensive component on the board, I soldered it last.

Cut the trace on the back of the board and short other two pads to boot from FLASH.

Toolchain

One of the great things about the ARM architecture is ready availability of compiler toolchains. Being on Linux, I use the summon-arm-toolchain script which makes building a up-to-date ARM toolchain trivial. Namely,

$ git clone https://github.com/esden/summon-arm-toolchain.git
$ cd summon-arm-toolchain
$ ./summon-arm-toolchain

After the script finishes you’ll find that you have binutils, gcc, and OpenOCD available in ~/sat. You can add these to your environment by,

$ PATH=~/sat/bin:$PATH
$ export LD_LIBRARY_PATH=~/sat/lib:$LD_LIBRARY_PATH

Hello World

The examples/blink program is a good starting point to verify the board. First, build the example,

$ cd mkchk/examples/blink
$ make

Now you have a blink.bin image ready to be uploaded to the mkchk. This can be done through one of the device’s two debug ports: the five-pin JTAG interface or the two-pin Serial Wire Debug (SWD) interface. The appropriate wiring configurations are shown in the tables below.

To interface with the device I used a Bus Pirate in conjunction with a variant of Will Donnelley’s pirate-swd. While Will’s description is helpful, details on the hardware configuration are pretty sparse.

Since I use SWD (due to its lower pin count) I will detail my experiences with this below.

Using the flashSTM32 program available in my pirate-swd Github repository, upload the new image,

$ python pirate-swd/flashSTM32.py mchck/examples/blink/blink.bin

If all goes well, you should see a variety of status messages, followed by a message informing you that the script has reset the device. Hopefully now you will see the LED on the device blinking.

If the script dies of a protocol error, don’t worry, there are many possible issues, few of which are serious. First double-check the wiring and ensure that the device has power. If this is the correct, next look at the three bits listed in the script’s error message. These are the acknowledgement bits of the frame during which it lost synchronization with the device.

If the acknowledgement bits aren’t all the same value, then you probably have noise on your clock line. This can be tested by placing your finger on the mchck’s SWD header pins. If the bus becomes more stable, this is evidence that your connection configuration is picking up RF noise from your surroundings, leading to false cycles. When using my Bus Pirate’s grabber cable, I found it necessary to place a capacitor between CLK and GND to provide better noise rejection. Without this the bus was extremely unstable.

Finally, if the acknowledgement bits are all either 0 or 1, things aren’t good; it seems the chip isn’t making any attempt at communicating. Double check your soldering, the orientation of the chip, and if all else fails try replacing it.