The Great MSP430 Bootloader Swindle

Bootloading Blues.


The MSP430 is a great little micro, and with some proper marketing, it could easily have provided an alternative to the AVR and PIC.  However unclear, obfuscating, archaic documentation, spread very thinly over the web has made this little micro the poor relation of the microcontroller world.

I write this having just spend a considerable amount of time in February trying to provide an effective solution for programming one of our products, an MSP430 based force gauge, which is being produced by a new supplier.

Unfortunately the original programmer from Gessler is no longer available, and so an alternative was needed.

The solution was actually staring in me in the face - so simple, that it's elegance seems to have been lost in the mists of time, and the desire to make everything a lot more complicated than it needs to be.

Here I summarise my findings in an attempt to provide a reference that will allow others to benefit from my 3 weeks of frustrating work and false starts.

As a prologue to the main post - here is an unpublished post from 3 weeks ago - when I first started on this mission

(Previously unpublished - from Feb 9th 2016)


We have an on-going project at work, which needs an MSP430 bootloading over it's serial port with a hex file.  So we went out and bought the cheap open source, Rocket BSL programmer from Olimex.

I then found that I needed the drivers and other software from TI,  which I had to register for and then declare to the US Government that I wasn't going to use it against America in any way, shape or form. So far, so good.

North Korean? No, just Bulgarian.

The MSP430-BSL is described as a joint project between Olimex and Texas Instruments. The reality is that no-one really wants to take ownership of it, and there is no one specific site that you can go to that gives you everything you need to get this programmer to work.  It's like the code has been fragmented and spread to the four corners of the known cyber world - lest anyone dares try put the fragments together again and unleash the awesomeness of this great force on mankind. What I'm trying to say is that both Olimex and the Mighty TI have this time shot themselves in both feet, and it's no surprise that the MSP430  is languishing in some stagnant microcontroller cul-de-sac.

After mulling this over for a while, I began to think that proprietary bootloaders often really suck. There should be a simple, low cost universal tool which allows you to squirt code from a hex file into any microcontroller, from any platform.  And that got me thinking about the humble USB-serial programming cable - such as those by FTDI, SiLabs or our Chinese friends who make the CH340.

It also appears that others have had this thought.  In my search for an alternative MSP430 programmer, I found this interesting approach from Flying Camp Design - a programmer that is literally not much more complicated than an FTDI cable - just an FT232R on a small pcb.

Bootloaders are usually designed to be small, and not particularly human-friendly, because they are normally talking to some proprietary application running on the pc.  But this doesn't need to be the case, there is sufficient flash space in the boot block of most micros to put a more sophisticated bootloader program - one which is actually capable of running some interpreted commands and presenting a more human friendly face to the user.




Getting Started

The MSP may be programmed by one or more of the following interfaces:

1.  A Serial Boot Loader - resident on almost all MSP430 devices - known as BSL
2.  A JTAG interface/programmer
3.  SpyByWire  - a 2 wire serialised version of JTAG.


The Electrical Interface

Our force gauge product has a 6 pin connector on board intended for a BSL programmer.  This has  the following signals present - wired to pins on the IC:

TX
RX
TEST
RESET
0V
VCC

A combination of signals on the test and reset pins puts the device into bootloader mode.  The data is then sent by the PC and received by the Rx pin and acknowledged by the Tx pin.

The Spec Document

The bootloader is fairly well specified in TI's document SLAU319 - and for anyone wishing to understand the bootloader, this should be the starting place.

When the MSP430 was first designed, the engineers made available a small bootloader program, residing in protected ROM, which allowed serial communication directly to a PC via a couple of pins. The BSL interface also allows you to read the contents of the Flash, erase it, verify and a range of other commands - some protected by a password mechanism  - so as to avoid illegal copying of protected IP.

Towards the middle of the SLAU319 document, a circuit for a programming interface is provided:

This circuit dates from the early 2000's  - when all PCs and laptops came with 9 pin serial COM ports.

In essence, there are three, level shifted outputs from the COM port to the target device, and one level shifted input back to the PC. Modern RS232 generally puts out +/-6V - and we need 0-3V TTL levels for the MSP430.  The circuit is powered by harvesting spare energy from the output lines through diodes and pumping up  a capacitor. The raw supply feeds the TL062 op-amp and  is then regulated to 3V to provide a stable supply for the 74AHC14 Schmitt inverters.

This really is a very simple circuit - but sadly off-putting because it uses about 25 components and uses the now obsolete  9 way D-type and COM port.

What is really needed is a modern equivalent that works with USB and modern software drivers.


USB Implementation.

There are several low cost USB to serial converter chips to choose from, including FTDI, CP2102 (SiLabs) and the newer Chinese CH340G.  All of them have the potential to work in this circuit.

I covered the CH340G in a recent post and the datasheet is here. The CH340 is low cost and easy to use. I have subsequently used the CH340G on some of my other projects.

For my experimentation, however, I used a  SiLabs CP2102 device mounted on a small pcb - solely because I had it lying about.  It breaks out all of the common RS232 signals - including RTS and DTR which we need.   These modular devices are available from ebay for a couple of dollars - and a variety to choose from.

CP2102 module by Baite Electronics 

The one above comes with a set of double ended leads - so you can easily make up your own custom cable.

So to make this work we need to access Tx, Rx, RTS and DTR.  RTS and DTR are often available on the 4 way headers down the side of the module.

The module also conveniently supplies a 3V3 supply from an internal voltage regulator (see datasheet) - this can supply a maximum of 100mA - more than enough for powering most MSP430 dev-boards.

Programming Application Software

I tried a couple of programming applications, with very little success - until I stumbled MSPFET - from a Russian gentleman Kurt. This did exactly what was needed - allowing a hex file to be loaded into the MSP430.

Programming the MSP430 really is that cheap and easy - using free software and a USB to serial module costing under $2 - finding out how to do it -  from the information spread over the web it - was so very much harder.

Common Myths - Busted

You don't need a $300 JTAG Programmer.  In desperation I found a FET-Pro 430 reduced to $50 on ebay.

You don't need an $11 Olimex MSP-BSP "Rocket" Programmer.  I bought two of these from Mouser - I am still trying to find the correct software to make them work.


In conclusion

The BSL feature that comes with almost all MSP430 devices is great at doing what it was intended for - a very simple means of getting your hex file into the MSP430's flash.

The resources needed to make this work are trivial, and it could make a great addition to any application that needs the ability to modify the flash memory.

Unfortunately, the documentation has been obfuscated and made more compex than needs-be by JTAG and SpyByWire (for debugging) - and so few people are aware what a simple facility BSL is to use.  The hardware needed in the form of a USB - Serial converter should be part of every hobbyist's or Engineer's toolkit.

The resources needed to make this work are trivial, and it could make a great addition to any application that needs the ability to modify the flash memory.

The protocol is simple, as is the 2 signal start-up sequence -  and at a pinch, if you didn't have a serial converter that supports DTR (eg FTDI cable) you could hack an Arduino or Launchpad to generate the start-up sequence. You could even make a standalone programmer for repeat programming of boards out in the field using a Launchpad.

Energia has made the MSP430 more accessible - providing an Arduino like development environment. However, it is still nice to know how the simple low-level bootloader scheme works.

Update

I have written a follow-up to this post:

The Great MSP430 Bootloader Swindle - Part 2

This looks at the hardware and PC applications needed to make the simple BSL work.

I have also implemented the CH340G bootloader circuit on my latest MSP430 board. Below, on the left is the CH340G, its accompanying 12MHz crystal and a couple of 22pF capacitors. That's almost all you need for a bootloading interface!

ChipStick - an 11mm x 40mm  MSP430FR2433 Dev Board

Building WiNode 5 - Part 3

Some five years have passed since the original WiNode design, and WiNode 5 - consider it to be the Anniversary Edition, has tried to build upon some of the changes that have happened over the intervening years. There has been an explosion of low cost wireless modules onto the hobbyist market, WiFi, Bluetooth Low Energy (BLE) and upgraded <1ghz an="" and="" be="" devices="" ism="" latest="" may="" modules="" mounted.="" of="" offers="" onto="" open-platform="" p="" some="" these="" this="" version="" which="" winode="">
More than just an ATmega1284 Platform

WiNode comes towards the end of my involvement with 8-bit microcontrollers - as I move towards 16 bit and 32-bit devices. For this reason it was designed with future proofing in mind.

Whilst a surface mounted ATmega1284 may be soldered to the pcb for the basic board, there is also provision for a 40 pin DIL socket or pair of female header strips to be fitted down the centre of the pcb.  If the ATmega1284 is not fitted to the board, then any other mcu of up to about a 48 pin package - suitably mounted on a small carrier pcb that matches the 40 DIL pin-out,  may be plugged into the board. The 40 pin "socket" is based around the pin-out of the DIL ATmega1284 - so even one of those can be fitted if necessary.

This technique allows the use of a range of small processors, including ARM Cortex M, MSP430 and the like. I already have prototype designs for STM32Fxxx and MSP430 microcontroller variants.

With the upgrade in processor, comes an increase in clock frequency, increase in memory, improvement in peripheral features and speed and often an increase in ADC resolution.

ARM Cortex M4 Variant

For instance, the STM32F373 - a 72MHz ARM Cortex M4 in a 48 pin LQFP package comes with 3 UARTS, 2 SPI, 2 I2C,  up to 256Kbytes of Flash and up to 32Kbytes of RAM, plus a multichannel  12 bit ADC and 3 separate differential input Sigma Delta 16 bit ADCs. The Cortex M4F core comes with floating point and DSP operations. This is the ideal processor for high speed manipulation of analogue sampled data - for example 3 phase energy monitoring.  These processors start at £3.33 in 1 off.

MSP430 Variant

Another interesting processor is the ultra low power MSP430 FR series.  These are a 16 bit processor with 24MHz clock frequency, 12 bit ADC channels, 2 UARTs, SPI and I2C.  The unique feature of the FR series is that they use non-volatile ferroelectric FRAM memory for program and data storage. This allows exceptionally low power operation, retaining data after power down and capable of very fast write access - for high speed programming or datalogging.

Other Interesting Options

There is an increased interest in the use of FPGAs as a means of providing open source soft core processors.  One such option is the J1 Forth processor implemented on a low cost Lattice FPGA - using an open source toolchain.  The FPGA is available in an 84 QFN package just 7mm x 7mm which could be fitted onto the DIL 40 carrier board.



The WiNode 5 Hardware and Peripherals

Here I describe the hardware in a little more detail:

All of the hardware on WiNode 5 is designed to work at a 3.3V Vcc - thus keeping power requirements to a minimum.  Think carefully before you connect to any non- 3.3V shield!

The RFM69 wireless transceiver is still very much fundamental to the design, tracing it's roots to Jean Claude Wippler's JeeNode design - which used the ATmega328 and the RFM12B - and was probably about one of the first commercial wireless connected Arduino variants.

The RFM69 uses D10 for it's chip select, and the new INT2 interrupt that is available on the ATmega1284 - appearing on D8.

In addition to the encumbent RFM69, WiNode 5 also offers an un-committed "X-Bee" footprint (XB1)  This allows any additional wireless device to be added at a later date - based on a shield that conforms to the X-Bee pinout.

One of the biggest advances in the last 2 years is the emergence of very low cost WiFi modules based on the ESP8266 device. WiNode provides a 4x2 connector to allow an optional ESP-01 WiFi module to be plugged in directly so that it can communicate with the mcu using the additional UART 1. Note that WiFi support is optional and not central to the WiNode philosophy. Using a pre-built mass-produced plug-in module is the quickest and cheapest way to give it WiFi connectivity.

The original WiNode used a non-volatile 32Kbyte 23K256 SPI SRAM - backed up by a small super-capacitor.  This feature has also been retained with IC3 a SOIC-8 package, but now the device can be an SRAM of up to 128Kbytes or a ferrroelectric FRAM of up to 256Kbytes. Chip selection is by port B0.

Whilst novel when first introduced on my Nanode RF design of 2011, the micro SD is now common place on many development boards and SBCs.  I have retained the same basic uSD socket - soldered to the underside of the pcb and selected using port D9.

With lower power, yet more capable microcontrollers, there is frequently the need to make portable battery powered devices.  With the emergence of cheap Lithium polymer (LiPo) battery technology, WiNode 5 reflects this with support for an external battery.  This does not need to be a LiPo as an on-board boost converter, IC6, based on low cost MCP1640 allows a single cell to be boosted up to 3V3 so as to power the board.

One of the biggest bug-bears 5 years ago was the crippling cost of placing an FT232R device onto the board in order to allow connection to a PC via USB. Fortunately there are now several much lower cost alternatives available, and WiNode 5 uses the CH340G device in position IC7 - which is available for less that $0.50. It needs a 12MHz crystal  Y3 for correct USB timing.

The ATmega1284 provides a whole additional 8 bit port over and above what the ATmega328 supplies.  Six of these additional port lines are broken out to a header which is placed below the usual 6 pin Arduino "Power" header.  These additional pins are general purpose I/O, but also carry the signals associated with the JTAG interface.

As WiNode 5 uses several SPI devices, the additional port lines C0-C5 can be used to select additional devices on the SPI bus - this offers an easy route for expansion. More on expansion later.



Board Pin Out Details

WiNode 5 has been designed to act either as a stand alone, battery powered, wireless connected controller or monitor,  alternatively as part of a larger system.


//                    _________________________________
//      PC-RXD0 (D0) |o            A7  (D29)          o|A5  (D27)
//      PC-TXD0 (D1) |o            A6  (D28)          o|A5  (D26)
//   * ESP-RXD1 (D2) |o            B0  (D30)          o|A3  (D25)
//   * ESP-TXD1 (D3) |o            B1  (D31)          o|A2  (D24)
//     KBD_DATA (D4) |o                               o|A1  (D23)
//           PD (D5) |o                               o|A0  (D22)
//    MOUSE_CLK (D6) |o                                |
//   MOUSE_DATA (D7) |o                                |
//                   |                                o|VIN
//    RFM_INT2  (D8) |o                               o|0V
//      uSD_CS  (D9) |o                               o|0V
//      RFM_CS (D10) |o                               o|+3V3
//        MOSI (D11) |o                               o|+5V
//        MISO (D12) |o                               o|RES
//         SCK (D12) |o                               o|C5  (D21)
//          0V       |o                               o|C4  (D20)
//        AREF       |o         Open Hardware         o|C3  (D19)
//     I2C-SDA (D14) |o            WiNode 5           o|C2  (D18)
//     I2C-SCL (D15) |o                               o|C1  (D17)
//         ANT       |O                               o|C0  (D16)
//                   |_________________________________|

One of the first applications is that of a retro-computer system using the EVITA graphics driver board (above).  EVITA provides 1024x768 full 24bit colour graphics and an interface for PS/2 keyboard and mouse. It also allows a Wii Nunchuck controller to be plugged in.

With just WiNode 5 and EVITA, you have a complete retro-computing work/play station capable of driving a large screen monitor in just 2 small pcbs.  For portability you can use a Gameduino2 shield and a LiPo battery.

The slight conflict yet to be resolved here is when using the PS/2 keyboard with the ESP-01 WiFi. The keyboard generates a clock which needs to interrupt the mcu via INT1 (D3).

If used with a Gameduino 2 - INT 0 (D2) is also required. This kind of precludes the use of the ESP-01 WiFi - unless a work around is possible.

PCB Layout

WiNode was designed from the start to be smaller than the standard Arduino (Uno) - always considered to be too bulky and "Arty" rather than a simple rectangular board with sensible pin spacing and mounting holes. At 55x64mm it was intended to fit into a readily available plastic case with a battery enclosure. WiNode used predominantly through hod mounted components wherever possible.

WiNode 5 takes advantage of surface mounted components - as it was found that even the through hole parts presented too much of a soldering challenge to the average user.  This means that the circuitry can have a greater density - thus a smaller pcb and be cheaper to assemble - using pick and place machines and reflow soldering ovens.  It is really geared up for the modern electronics pcb assembly processes.  As a result, WiNode 5 packs a lot more functionality into a 50mm x 50mm pcb - some 71% of the board area of it's predecessor.

Whilst WiNode 5 can be hand soldered - it will take a few hours and you really need to be proficient at surface mount detailed soldering, have good light and good magnification available.

The board is based on a 50 mm x 50 mm standard footprint - with the aim of retaining Arduino header compatibility on the smallest pcb possible.   WiNode takes advantage of pre-built plug in modules - such as the ESP-01, the adxl 335 accelerometer module and the X-Bee module.  These can be bought on ebay cheaper than they can be built.

Building WiNode 5 - Part 2

Pin Mapping

WiNode 5 is the successor to earlier WiNodes that were based on the 28 pin DIL ATmega328.  

The ATmega1284 offers significantly more features and GPIO pins, 32 compared to the 20 of the ATmega328 - and these all have to be mapped out in a way that makes sense on the PCB. There is also a constraint of 28 header pins - so four of the GPIO appear elsewhere on the pcb - for specific functions - see later.  

There is no common standard, with several commercial ATmega1284 boards doing their own thing - generally based on the 40 pin DIL version of the ATmega1284.

Reverting to good ol' ASCII Art -  Here is one mapping scheme from "Mighty1284P"

//                       +---\/---+
//           (D 0) PB0  1|        |40  PA0 (AI 0 / D24)
//           (D 1) PB1  2|        |39  PA1 (AI 1 / D25)
//      INT2 (D 2) PB2  3|        |38  PA2 (AI 2 / D26)
//       PWM (D 3) PB3  4|        |37  PA3 (AI 3 / D27)
//    PWM/SS (D 4) PB4  5|        |36  PA4 (AI 4 / D28)
//      MOSI (D 5) PB5  6|        |35  PA5 (AI 5 / D29)
//  PWM/MISO (D 6) PB6  7|        |34  PA6 (AI 6 / D30)
//   PWM/SCK (D 7) PB7  8|        |33  PA7 (AI 7 / D31)
//                 RST  9|        |32  AREF
//                 VCC 10|        |31  GND 
//                 GND 11|        |30  AVCC
//               XTAL2 12|        |29  PC7 (D 23)
//               XTAL1 13|        |28  PC6 (D 22)
//      RX0 (D 8)  PD0 14|        |27  PC5 (D 21) TDI
//      TX0 (D 9)  PD1 15|        |26  PC4 (D 20) TDO
// RX1/INT0 (D 10) PD2 16|        |25  PC3 (D 19) TMS
// TX1/INT1 (D 11) PD3 17|        |24  PC2 (D 18) TCK
//      PWM (D 12) PD4 18|        |23  PC1 (D 17) SDA
//      PWM (D 13) PD5 19|        |22  PC0 (D 16) SCL
//      PWM (D 14) PD6 20|        |21  PD7 (D 15) PWM
//                       +--------+

This is a fairly logical approach, with pins numbered starting from Pin 1 of the package and just following the package around.  However it does not tie in well with the mapping on the Arduino or WiNode 5 board:

The Bobuino pin mapping is much more like the original Arduino - preserving D0 to D13 in their old familiar positions and functions, plus the analogue inputs mapped to D14 to D21, and the additional (Port C) pins following on as D22 to D29. This just puts SCL and SDA a little bit off beat as D22 and D23.  The mapping scheme is better but not perfect:

//
//                       +---\/---+
//           (D 4) PB0 1 |        | 40 PA0 (D 21) AI 7
//           (D 5) PB1 2 |        | 39 PA1 (D 20) AI 6
//      INT2 (D 6) PB2 3 |        | 38 PA2 (D 19) AI 5
//       PWM (D 7) PB3 4 |        | 37 PA3 (D 18) AI 4
//   PWM/SS (D 10) PB4 5 |        | 36 PA4 (D 17) AI 3
//     MOSI (D 11) PB5 6 |        | 35 PA5 (D 16) AI 2
// PWM/MISO (D 12) PB6 7 |        | 34 PA6 (D 15) AI 1
//  PWM/SCK (D 13) PB7 8 |        | 33 PA7 (D 14) AI 0
//                 RST 9 |        | 32 AREF
//                VCC 10 |        | 31 GND 
//                GND 11 |        | 30 AVCC
//              XTAL2 12 |        | 29 PC7 (D 29) 
//              XTAL1 13 |        | 28 PC6 (D 28) 
//      RX0 (D 0) PD0 14 |        | 27 PC5 (D 27) TDI
//      TX0 (D 1) PD1 15 |        | 26 PC4 (D 26) TDO
// INT0 RX1 (D 2) PD2 16 |        | 25 PC3 (D 25) TMS
// INT1 TX1 (D 3) PD3 17 |        | 24 PC2 (D 24) TCK
//     PWM (D 30) PD4 18 |        | 23 PC1 (D 23) SDA
//      PWM (D 8) PD5 19 |        | 22 PC0 (D 22) SCL
//      PWM (D 9) PD6 20 |        | 21 PD7 (D 31) PWM

//                       +--------+

My problem is that pins B0 and B1 are not routed to the regular headers but appear on the upper H-bridge connector JP4 and the "X-Bee" shield. Additionally Analogue inputs A6 and A7 are used on board for battery volts and battery temperature monitoring. These rogue pins need to be accounted for in the mapping scheme.This therefore gives rise to the modified arrangement:

//
//                         +---\/---+
//            (D 30) PB0 1 |        | 40 PA0 (D 22) AI 0
//            (D 31) PB1 2 |        | 39 PA1 (D 23) AI 1
//        INT2 (D 8) PB2 3 |        | 38 PA2 (D 14) AI 2
//      PWM0A  (D 9) PB3 4 |        | 37 PA3 (D 25) AI 3
//   PWM0B/SS (D 10) PB4 5 |        | 36 PA4 (D 26) AI 4
//       MOSI (D 11) PB5 6 |        | 35 PA5 (D 27) AI 5
// PWM3A/MISO (D 12) PB6 7 |        | 34 PA6 (D 28) AI 6
//  PWM3B/SCK (D 13) PB7 8 |        | 33 PA7 (D 29) AI 7
//                   RST 9 |        | 32 AREF
//                  VCC 10 |        | 31 GND 
//                  GND 11 |        | 30 AVCC
//                XTAL2 12 |        | 29 PC7 (D 21) 
//                XTAL1 13 |        | 28 PC6 (D 20) 
//        RX0 (D 0) PD0 14 |        | 27 PC5 (D 19) TDI
//        TX0 (D 1) PD1 15 |        | 26 PC4 (D 18) TDO
//   INT0 RX1 (D 2) PD2 16 |        | 25 PC3 (D 17) TMS
//   INT1 TX1 (D 3) PD3 17 |        | 24 PC2 (D 16) TCK
//      PWM1B (D 4) PD4 18 |        | 23 PC1 (D 14) SDA
//      PWM1A (D 5) PD5 19 |        | 22 PC0 (D 15) SCL
//      PWM2B (D 6) PD6 20 |        | 21 PD7 (D 7)  PWM2A
//                         +--------+ 


With any pin-mapping , it is clearly a compromise between physical and logical arrangement. These changes can be incorporated into the pins_arduino.h header file. We achieve a mapping that is reasonably familiar with existing Arduino pin-out and ties in well with the physical layout of the pcb:


//                   _________________________________
//        RXD0 (D0) |o            A7  (D29)          o|A5  (D27)
//        TXD0 (D1) |o            A6  (D28)          o|A5  (D26)
//   RXD1 INT0 (D2) |o            B0  (D30)          o|A3  (D25)
//   TXD1 INT1 (D3) |o            B1  (D31)          o|A2  (D24)
//       PWM1B (D4) |o                               o|A1  (D23)
//       PWM1A (D5) |o                               o|A0  (D22)
//       PWM2B (D6) |o                                |
//       PWM2A (D7) |o                                |
//                  |                                o|VIN
//       INT2  (D8) |o                               o|0V
//      PWM0A  (D9) |o                               o|0V
//   PWM0B/SS (D10) |o                               o|+3V3
//       MOSI (D11) |o                               o|+5V
// PWM3A MISO (D12) |o                               o|RES
// PWM3B  SCK (D13) |o                               o|C5  (D21)
//         0V       |o                               o|C4  (D20) 
//       AREF       |o         Open Hardware         o|C3  (D19)
//        SDA (D14) |o            WiNode 5           o|C2  (D18)
//        SCL (D15) |o                               o|C1  (D17)
//        ANT       |O                               o|C0  (D16) 
//                  |_________________________________|

This makes for a neat, logical arrangement, where the pairs of complimentary PWM outputs are located next to one another - and in a neat group D4-D7.

SCL and SDA are on the end of the upper digitals - where you would expect them on an R3 shield.  

The JTAG lines (TCK,TMS, TDI,TD0) are in a neat group on the extended headers C0-C5.  C4 and C5 may be used for active signalling to the shield through the Arduino I/O and NC pins on the end of the power header.

ANT is the antenna connection to the RFM69 wireless transceiver module.

In part 3 we further name and map these pins to suit the EVITA graphics shield and the Open Inverter H-bridge module.

Building WiNode 5 - Part 1

Bare Board, 2 layer, 50mm x 50mm

Two weeks ago, you may remember I finished the pcb layout for a new microcontroller board - WiNode 5  - based on my 50 x 50mm standard board footprint.

Minimum Build.

With mcu, reset and crystal fitted, the board runs "Blink"code

For this I suggest fitting the ATmega1284 SMT package, the 16MHz crystal and its two 22pF capacitors C14 and C15.

Also the 10K reset resistor R1 and the FTDI 6way right-angled header JP1.

A 3.3V  MCP1702 regulator should be fitted in position IC4 along with C2, C4 and C5 its input and output capacitors.

Fit the four 100nF decoupling capacitors around the main microcontroller, C3, C7, C12 and C19.

The 3x2 pin ICSP programming header JP6 should also be fitted.

For LED output fit green LED1 and its 100R series resistor R10.

With this minimum build you may power the board from the FTDI cable and now program the bootloader using ICSP.  If this is successful, loading the blinky sketch should run and the LED should flash.

Now we add the USB chip IC7 (CH340G) the USB connector and the 12MHz USB crystal. Add the 22pf capacitors C18 and C20 and the 100nF decoupling capacitor C20.

Fit capacitors C8, C9  and resistor R2 to provide a filtered AVCC supply.

Add the RFM69 Wireless, the USB and the ESP-01 WiFi

The RFM69 wireless module and the ESP-01 WiFi connector and module can be added at this stage.

Finally - fit the four female shield mounting headers.

Fit the "Arduino" style female socket strips

These allow complete shields to be added, or small modules like the accelerometer module - which is powered by and connected to the Analogue Input port

With axdl 335 Accelerometer module fitted

Programming and Firmware

The Optiboot loader and Arduino "board"  files for this project are located at the Mighty1284 Github repository - with more information about the ATmega1284P implentation of Arduino here.

With the new 1284 board files loaded into the hardware directory of the Arduino IDE, you are now ready to program the Optiboot loader into some chips.


Having got the basics of the board in place, and proven that all was working so far, it was at a stage where it could be left  and I could get some sleep.

The final construction stages were to populate the boost converter, fit the FRAM (or SRAM) IC and fit the micro SDcard socket to the underside of the board.

WiNode 5 virtually complete - topside view

Above - the boost converter components, IC, 5 resistors, 2 capacitors and an inductor are added to the lower right corner of the board.

Just above the mcu is the SOIC-8 FRAM IC.

The microSD card socket is added to the underside of the pcb.

And a final word from our sponsors..... Ragworm provided additional boards at no extra charge and couriered them over in time for some weekend fun, as my job is putting the first few boards together.

Experimenting With New Devices - Part 2

The '5969 Launch Pad  - an ideal experimenting platform for FRAM

In this post I look at ways in which to get the most performance out of a small computer system based around the MSP430FR5xxx with external serial  RAM and FRAM.

MSP430 Performance

The MSP430 being a 16 bit architecture is pitched performance-wise somewhere between AVR and ARM.

If you are doing a lot of 16 bit maths operations, then it will be quicker than the AVR as these are single cycle operations on registers, rather than having to combine two 8 bit operations.

This report compares execution time and code size for a number of common microcontrollers, in particular comparing MSP430 with ARM and AVR.

The speed up factor over an ATmega328 Arduino is as follows:

Simple Maths       1.27
FIR Analysis        3.29
Dhrystone            1.83
Whetstone           2.56

Average               2.24

When this is combined with a 24MHz clock - rather than the normal 16MHz clock on the Arduino the average speed improvement is approximately 3.35.

Code execution is fastest from RAM, so an important speed improvement will be achieved by copying all commonly used code from FRAM to SRAM at initialisation time. This copying process is extremely fast with 1Kbytes of FRAM memory contents copied to SRAM in approximately 128uS.

SIMPL on the MSP430

I tried SIMPL back in 2014 on a very low spec MSP430 value line device in a 20 pin DIL package with only 512 bytes of memory. The C code for SIMPL was compiled using the Energia IDE. There was no difficulty porting what had been an Arduino sketch to Energia - what runs under Arduino runs on an MSP430 under Energia, with zero or very little modification to the sketch. Only the lack of RAM on the MSP430G2553 device was a little problem.

Porting SIMPL to a FRAM Device.

Boosted by the initial success with the MSP430 Launchpad, in getting a basic version of SIMPL to run, I decided to invest in a couple of FRAM based devices.

First, I tried identical sketches on the ATmega328 and the MSP430FR5969.  This was purely so that I could prove that they both ran as expected, and so I could compare the codesize and execution time for each implementation.

For the same clock frequency of 16MHz, the MSP version used about 80% of the codesize and executed simple loops containing integer maths at about 25% improved time.

It was now time to reduce the Arduino supplied UART routines (Serial.xxx) to self coded putchar, getchar and printlong.  This process removed 2200 bytes of code from the implementation - down to 3720 bytes from a starting point of 5920.

The other large chunk of code is the array allocated to holding the initial word definitions. This is a 26 x 48 character array (1248 bytes) - which when removed brings SIMPL down to about 2472 bytes.

The other thing I noticed was that whilst the UART routines take just less than 300 bytes to implement, when they are combined with setup(), the whole thing bloats out to about 640 bytes. This needs further investigation because without this bloating, SIMPL could reside in just 2Kbytes of memory.

Making Use of the FRAM.

The question now is what new features can SIMPL leverage off the back of the MSP430's FRAM?

The write speed of FRAM is well matched to the higher baudrates of the USB to serial converter. Instead of 9600, we can now upload source code at 921600 baud or higher. Using a hex file format, a full 16Kbytes of code could be sent over the serial link in about 0.25 seconds.

The FRAM may be written to at 125nS per 16 bit word, so the whole FRAM storage space could be updated in about 1 milisecond.

The 10 bit ADC could send data back to the PC at almost 100ksps.

Execution from RAM is 3 times faster, so the primitives and the SIMPL kernel are loaded from flash into RAM during initialisation.

The MSP430 has a 20 bit address space, so up to 64 blocks of code could be swapped into FRAM when required.

Off chip storage could be uSD card or even serial FRAM - such as the Cypress 25LV20   which is a 256Kx8 SPI FRAM device in an 8 pin SOIC package.  The SPI bus runs at a maximum of 10Mbit/s - so a "block load" of 1Kbytes is approximately 1mS or the time to load a full 16K block from external FRAM via SPI is 14mS.  This is effectively 1uS access time to a large non-volatile solid state drive.

For faster access either dual SPI or Quad SPI would need to be employed.  This can be done using bit-banging techniques using quite elementary code.

See the Microchip App Note AN1791 for details. A datarate of 8Mbyte/s should be achievable. This would allow the 23LC1024 to be fully read in about 16mS.

To be continued...... soon

Experimenting with New Devices - Part 1

If you were to summarise the developments in microcontrollers over the last few years, you might suggest the movement to 32-bit, mainly through ARM devices, and the rise in open source hardware and software.

Another less well known development is the incorporation of Ferroelectric RAM or FRAM as an alternative to flash memory in the Texas Instruments (TI) range of MSP430 microcontrollers.

Using FRAM instead of Flash memory opens up some interesting possibilities:

FRAM is non-volatile - it retains it's content after power down
It is low power - it can be programmed at low voltages
It has a fast write speed - up to 8Mbytes per second - about 100 times faster than flash
It can be used repeatedly like RAM - it does not wear out after some 10,000 cycles like Flash

Whilst I did gain some experience of the MSP430 some 12 years ago, the introduction of FRAM and modernised peripherals makes them an attractive proposition.

So I decided to invest a little time and money in exploring the new architecture and the new opportunities presented by FRAM technology.

This post and subsequent posts will look at these topics and make a comparison between the more familiar AVR and ARM based devices.

MSP430 Family.

The MSP430 is a 16-bit RISC type microcontroller, with a Von Neuman architecture. This is unusual for microcontrollers (most are Harvard architecture), as it combines both the instruction store and the data store into one unified memory area.

It arose from an early 1990's devices, which was an 8 bit processor, the TSS400-S2, for interfacing to sensors. This early datasheet gives some insight into the heritage from 25 years ago.

The memory architecture is further simplified, as the FRAM and SRAM blocks can essentially be treated as the same codespace for program execution, although execution from RAM is at up to 24MHz, whereas executing from FRAM is limited to 8MHz.

Energia - "Arduino" for the MSP430

The MSP430 range has been supported with low cost "Launch Pad" development boards since 2010, providing an alternative to the AVR or ARM based Arduino or mbed boards. This support extends to the open source Energia IDE project - which is essentially an Arduino compatible IDE (and lookalike) aimed at the various TI microcontroller families. With Energia you can take an existing Arduino sketch and run it directly on MSP430 hardware, with no or few changes. Arduino is certainly becoming a lingua-franca of these small dev-boards.


A look at the MSP430  FRAM devices

The two devices I wanted  to explore are the MSP430FR57xx series and the MSP430FR59xx series.   The MSP430FR5739 is available as as an Experimenter board - below.

The FR57xx series is the smaller of the two with 16Kbytes of FRAM and 1Kbytes of RAM and a maximum clock of 24MHz. It costs about £1.50 in 1off from Farnell and has the potential as being an alternative to Arduino (Nano beater)  - with very few other system components required.  It has 30 GPIO lines which makes it a very good fit for the WiNode 5 format pcb with the extended Arduino headers. Available in a 38pin TSSOP package, which makes it a little easier for home construction.

The FR5969 has 64kB of FRAM, 2K of RAM and a 16MHz clock.

It offers 40 GPIO pins, plus the ability to use both high frequency (16MHz) and low frequency (32768Hz) crystals.

It comes in 40 pin QFN and 48pin QFN packages. A slightly smaller device- with marginally less I/O, the '5959 is available in a 38 pin TSSOP, making it compatible with the '57xx parts but with the beneffit of 64K FRAM and 2K RAM

The MSP430FR5969 is available as the MSP-EXP430FR5969  as a Launch Pad board - for about £12 from Mouser.  This is exceptionally good value, and it has a number of accessory shields available.

Basic Features.

16 bit Von Neuman RISC architecture with 16Kbytes / 64Kbytes  FRAM
16MHz (24MHz *) clock frequency
1.8V to 3.6V operation
100uA/MHz low power operation.
0.25uA RTC
Multiple low power modes of operation
32 bit hardware multiplier
Choice of 10 bit or 12 multichannel ADC
2 UARTS,  SPI, I2C
5 Timers
Low power oscillator
Optional external 32kHz crystal
Optional HF Crystal
16 bit CRC
128 bit/256 bit AES Encryption/decryption processor
31, 33 or 40 GPIO lines depending on package.
Available in 38 pin TSSOP, 40QFN, 48QFN packages.

* Whilst the data sheet says 16MHz, it is perfectly possible to get the digitally controlled oscillator DCO to run at 24MHz. This might be good for a "Turbo-Boost" mode - when power is available.

Datasheet is here.

Tools & Equipment

The Launch Pad and Experimenter boards come with an on-board programmer section, which allows a hex file to be programmed into memory and allows debugging.

The TI Code Composer compiler and tool chain is distributed free of charge for working with these small boards.

If you want to try an open source compiler there is MSPGCC, and if you are seriously into command line hardcore development , you could try  Michael Kohn's  naken_asm which is a cross assembler for a wide variety of microcontrollers.

There are several free tools for loading the hex file into the MSP430. One that I tried is Elprotronics FET Pro-430  Lite  which worked well with the on-board eZ-FET programmer on the launch pad board.

With the above tools I managed to flash a LED using assembly language and also drive a port line at about 2.5MHz square wave.

In Summary & Conclusion

The MSP430 are a fascinating family of microcontrollers. They have utilised every trick to achieve flexibility and very low power operation.  The clocking and low power modes are a study in their own right - but TI through their Launch Pad series of dev boards have made a feature of low power operation - and encourage users to measure the operational current under various modes of working.

Not only is it a 16 bit machine, but it has a universal storage space  - both code and data in one memory - which is all the more interesting for being non-volatile, high speed FRAM.

Although a RISC machine, the ISA is surprisingly versatile with a rich set of instructions and addressing modes.

Just exploring a new instruction set is fun in itself.

The 16 bit architecture is an ideal platform for developing Forth like languages - as these are often based on a 16 bit virtual machine.  Jean-Michel Thooren's "Fast Forth" written in assembly language for the MSP430FR5969 may be of interest to Forth Fans.

Here is a very interesting device - it has a 16 bit architecture, 12 bit A to D and a Von Neuman architecture.  It reminds me a bit of the PDP-8.  More exploration needed.

In Part 2 I'll be looking at porting some existing code to the MSP430 and leveraging some Arduino sketches using Energia.

Fignition Revisited

The original WiNode 4.0 plus Evita video board 

Recently I have been thinking again about simple 8-bit computer systems.  By simple, I mean understandable, to me, and those that don't rely on 20 million lines of someone else's code to get to the point that you can have fun with them.

The early 1980s was a very prolific period of design for home computers, especially in the UK, before the very costly IBM PC really took a hold. Costly in the fact that it cost about £3000 in 1981 and very costly to the UK computer industry.

Many of these, now 35 year old computers are being revisited and recreated, possibly using new hardware, to create a whole genre of neo-retro machines.

Some History.....

Way back in 2011, I developed an "augmented Arduino"  which I called WiNode - a concatenation of Wireless Node.

It featured the ubiquitous ATmega328, an RFM12B 433 wireless transceiver, a real time clock, a microSD connector, a 32kbyte battery backed SPI SRAM and a dual H-bridge for driving small motors and relays.

One of the production batches of WiNode was used in a sound-sculpture installation "Phantom Railings"  at Malet Street Gardens in summer of2012.

About the same time, whilst at Oggcamp 2012, I met Julian Skidmore, who had created a small DIY kit for an 8-bit Forth Computer, called Fignition.

Julian had done a great job in getting it to run a very capable implementation of Forth, and produce audio and video from just an ATmega328.

The Plan.....

Whilst recently reconsidering the role of 8-bit computers, and languages such as Forth, I remembered Julian's work, and WiNode, and wondered whether they might both benefit from an upgrade.

I have subsequently upgraded WiNode to use the much more resource rich ATmega1284, with 16K of onchip RAM and 128K of flash.  By my reckoning that probably puts it on par with an original 16K Spectrum. However, according to Julian's Forth benchmark figures, when clocked at 16MHz, an ATmega is going to outperform a 3.5MHz Z80A by a factor of about 24.

In the intervening years, Fignition has gained a PS/2 keyboard interface, and is now showing all the signs of a very useful machine for learning to program in Forth. It easily exceeds all the capabilities of the early 1980's Jupiter ACE.

The new WiNode design is a good way of taking the Fignition concept a stage further.   It provides much needed additional RAM capacity,   the super-capacitor backed 32kbyte SPI SRAM can now be used as a persistent store - rather than the main execution RAM  - a much needed speed increase, and the microSD card may be used for removable program storage, put all your favourite Fignition games on uSD and share with your friends.....

WiNode also brings on-board wireless connectivity, either using the RFM69  433MHz or 868MHz low power transceiver, or the plug-in ESP8266 WiFi module.

WiNode by itself is really intended as a stand alone controller, with 28 general purpose I/O lines. The realtime clock, LiPo battery support and non-volatile RAM/uSD card means that it is a good fit for data logging, central heating control, internet connectivity (WiFi) , energy monitoring etc.

However, WiNode 5 has been designed to work with a video generation shield, called Evita, which allows full colour video of up to 1024x768 65Hz resolution via a VGA connection to a large screen monitor.  The Evita board also provides PS/2 keyboard and mouse interfaces, audio output, connection to a LCD touchscreen and also to a joystick or Wii Nunchuck controller. All the right interfaces for a colourful neo-retro computer system.

A Universal Microcontroller & FPGA Breakout Board mounted on WiNode 5

Last November, I devised a new compact pcb footprint on a 50 x 50mm board, and I have started to create a number of boards based on this format.

In November's blogpost, I speculated about using the board as a universal format for creating small microcontroller and FPGA boards, which share common peripherals and a standard pin-out ports for interconnectivity and "stackability".

The boards are fitted with "Arduino like" expansion shield headers - which themselves have been extended to provide connection for up to 28 GPIO signals, arranged nominally in four headers A, B, C, D.

The ports have been generally based on the arrangement on the ATmega1284, which in a 40 pin DIL package provides four, 8 bit ports with the power pins & clock oscillator pins located towards the centre of the package. This a compact, logical arrangement, which makes the most of what can be packed into a 40 pin DIL.  (In the late 1970's manufacturers were very resourceful on how to package an 8 bit microprocessor with 16 address lines into the standard 40 pin DIL package).

The purpose of the breakout board is to put a complete microcomputer system into an easy to use, compact format.  This was the strategy adopted with WiNode which uses the ATmega1284, but which I am now extending to allow for further offerings from ARM and FPGA devices.

With ever increasing sophistication of microcontroller products, the pin-counts are rapidly rising - so it becomes a challenge on just how to access all of the GPIO pins for breakout, especially when some LQFP packages have 208 pins!

Whilst the extended Arduino headers can handle up to 28 GPIO, clearly another strategy is needed for the larger packages.

From my experience with WiNode, it is very easy to quickly use up several GPIO lines just supporting the on-board peripheral hardware devices:

microSD card        SPI bus +  /CS
RTC                     I2C  + interrupt
SRAM                  SPI + /CS
Keyboard              Clock, Data,
Mouse                  Clock, Data
Wii Nunchuck       I2C
FT812                  SPI, /CS
USB                     UART RX0, TX0
WiFi (ESP-01)      RX1,TX1
RFM69                SPI + /CS + interrupt
Battery Volts        ADC
Battery Temp       ADC

So 20+ lines can easily be consumed with the on board devices.  Incidently, the WiNode 5 has been designed so that it will support other processors in addition to the ATmega1284, in this role it becomes a compact I/O shield.

ARM Challenge

Adopting this format to the larger parts will require a different strategy.  Do we assume that almost all of the "Arduino" pins will be consumed with the local peripherals and that a bus strategy should be employed for inter-board communications?

For ARM packages up to 48 pins, the solution is to craft the device GPIO ports into a 40 pin DIL format, such that it can be plugged directly into the WiNode board. This will take care of the essential system peripherals, leaving the remaining lines available for a bus connector.

On the ARM processors, this is likely to connect directly to the Flexible Memory Controller (FMC). As this is involves a lot of signals, a more dense connector format will be required - and 1.27mm pitch would double the connector density yet remain compatible with 2.54mm standard pitch connectors.

The larger package ARM processors have the FMC external memory controller and also a parallel LCD controller interface - both of which are very intensive in terms of pin usage. These should be routed out to the high density "bus" connectors.

As a rule of thumb - the first three 16 bit ports A, B, C on the ARM will be routed out to 2.54mm headers - based on an Arduino compatible theme.  The higher ports D,E,F,G,  H,I,J & K will be routed to their own double density connectors at either end of the pcb. This format will give maximum flexibility, for the larger pin packages, including memory and FPGA devices.

Trial Fitting a 208 pin processor and a 72Mbit 3nS SRAM

This arrangement will allow unique breakout for up to 156 GPIO signals (The 208 pin STM32F746 or STM32F439BGT6 have a maximum of 166 GPIO lines).

The signals unlikely to leave the board are the clock oscillators PC14, PC15, PH0, PH1,  the JTAG/SWD/ST- link signals PA13, PA14, PA15, PB3, PB4 - which will have their own header.

External Memory Connector.

This 64+4 pin connector handles 32 data lines, 24 address lines and control signals.

LCD Display Connector.

This 64+4 pin connector handles 24 bits of RGB data,  synchronisation signals and pixel clock along with other LCD control signals. It is arranged such that a flexible plastic connector (FPC) common on LCD screens can be easily interfaced .

Clearly a work in progress - the weekends are just to short.

WiNode 5 Update

Two weeks ago, I posted about an update to the WiNode, well here's that long awaited update - now that I have finished the pcb layout and submitted it for manufacture.

The board has had some radical design changes since the first conceptual design - and hopefully I have got a very flexible platform for control and datalogging applications.

In it's original form, the layout proved a little too complex for the size of board available - which meant that it was a real pain to route.  So I tried dropping tracksizes first from 10 thou to 8 thou and then from 8 thou to 6 thou.  I then realised that it was still going to be a routing nightmare, so I came up with a Plan B, which was to ditch some of the more complex functions and come up with a good all round ATmega1284 board.

So I retained the RFM69 wireless module and the microSD card, the RTC, and 32K battery backed SRAM but unfortunately the dual H-bridge just has to wait for the next bus.  This means that the ATmega1284 design will not be held up waiting to get a very tight route done.

A Slimmed Down WiNode 5 Board - initial component placement.

I managed to spend most of my free time in the evenings and weekends of the last couple of weeks fighting the EagleCAD autorouter.  In the end I decided that the pcb was just too hard to route with the available tool and algortithms, so I decided that there was only one final solution - and to route it by hand.

Latest Update - February 4th 2016

So here is the latest design, still a 50mm square board with all if the ATmega1284 pins brought out to a standard header format.  It can still connect to two of the Open Inverter power boards, which was the original design brief.

There is also a footprint towards the top of the pcb bsed on the X-Bee, which will accept any plug in wireless module on a carrier pcb. In addition, you may notice the outline of a 40 pin DIL socket. This will allow the DIL version of the ATmega1284P to be plugged into a turned pin socket.

After the culling of the Real Time Clock, the 32K SRAM and the dual H-bridge there has been a partial reprieve  - the RTC and SRAM have been re-instated, as has the boost regulator - which allows the board to run off a lithium cell, or even a single 1.5V alkaline cell.

Earlier in the week I wrote about the CH340 USB to serial converter IC. I have included this and a mini-USB B connector - located in the top right corner of the pcb.  This means that the board will run from multiple power sources for maximum flexibility of applications.

The almost final design after 12 hours overnight session of hand-routing!

Job Done!

After some serious burning of the midnight oil, I pushed the remaining tracks into a layout that I (and the EagleCAD DRC) was happy with (see below) and the Gerbers have been sent off to Ragworm - my local pcb supplier.

This is probably the last 8-bit/AVR board that I will do, as it kind of creates the platform that I wanted some years ago.  The extra 16K of RAM on the ATmega1284 will make it useful for bigger, more demanding applications, and the ability to accept wireless and WiFi modules from a variety of sources should make it useful - for example as an RFM69 to ESP8266 bridge.  The uSD card for datalogging and the RTC for turning things on at given times of day have it destined for all my old favourite central heating controller projects - and within a few weeks I should have a relay shield laid out for it.

The board also has been designed to be compatible with the EVITA graphics engine I designed over Christmas - and that has the means to provide high resolution colourful graphics on a big screen - and I must admit that I'm looking forwards to some big, bold colourful chunky graphics and some neo-retro computing projects.   The ATmega1284 is compatible with GameDuino2 - and so can leverage off of that graphics library. The 2 board stack of WiNode plus EVITA will make a great little retro platform - with PS/2 keyboard and mouse interfaces and the means to accept a Wii Nunchuck controller too!

Final Design Specification

ATmega1284P  with 128K Flash and 16K SRAM - either SMT package or 40 pin DIL package.
microSD card socket on underside of pcb
32Kbytes battery backed SPI SRAM (Microchip 23K256)
Real Time Clock / Alarm / NV RAM  (Microchip MCP79410)

Hope RF RFM69 low power wireless module (433 or 868MHz)
Socket to accept ESP8266-01 WiFi module
Socket to accept X-Bee or any pin compatible device

CH340 USB-serial adaptor - connection via mini B USB
FTDI standard cable connector for debug/programming
Reset switch, and RTS automatic reset when programming from Arduino IDE.

Lithium Polymer battery support
Boost regulator ((Microchip MCP1640) boost from 1V to 5V for LiPo or battery operation
250mA 3V3 linear regulator
Battery temperature and voltage monitoring via on-chip ADC

Extended "Arduino" style expansion headers  with 6 extra GPIO pins
Mini-application headers - 2 off, with 5V, 0V.  2x digital 2x ADC  and 2x PWM outputs
ATmega ICSP programming header 2x3 way
Standard 50mm x50mm 2 layer pcb format with 2 diagonally opposite M3 mounting holes.

Final Design as sent off to Ragworm - my local PCB Supplier

Two weeks later,  I receive 25 boards from my local supplier

The prototype WiNode 5 board prior to assembly.