PSoC4 debug with the Pioneer kit

In this article I will talk a little about the Cypress PSOC4 family of devices. Then I will explain the method I use to debug a cheap CY8CKIT-049-42XX board using a not so cheap CY8CKIT-042 Pioneer kit.

Cypress PSOC 4

Cypress PSOoC 4 is an interesting blend of MCU and programmable logic. It includes an ARM Cortex M0 CPU together with some programmable logic all in one chip. That way you can develop a system not only a MCU brain but also some custom digital peripherals. The Cypress web site has more information about it so I will not explain any further.

One interesting point about those devices is that the developement software PSoC Creator is freely available from Cypress alhough it is a Windows only application.

PSOC Creator 3

The application enables to develop both the programmable logic and the MCU programs. The glue code to link the program to the digital devices is created on the fly. It should be easy to develop an application in no time alhough I have not dedicated much time to explore the IDE features.

CY8CKIT-049-42XX Board

Texas Instruments broke the low level MCU development hardware with it's Launchpad when they sold it an only 5€ (now it is about 10€). Now Cypress is following the same path with its CY8CKIT-049-42XX board. This board sells for about 4€ and for it's price it's good deal. I bought mine at Farnell.

CY8CKIT-049-42XX

Cypress also sells another board, the CY8CKIT-049-41xx at the same price. But as it is a less featured board at the same price so I don't recommend it.

The board is a two part construction that can be directly connected to a free USB port. The left part of the board, that includes the USB connector, include a CY7C65211-24LTXI devide that implements an USB to serial bridge. The right part of the board includes the main chip of the board, a PSoC4 CY8C4245AXI-483 in a TQFP 44 pin package. A little pushbutton and a blue LED act as a minimalist peripheral set and complete this side of the board.

The CY8C4245AXI-483 main chip features a 48MHz ARM Cortex M0 MCU with 32kB flash and 4kB SRAM memories. It also includes a 12 bit SAR ADC, a pair of operational amplifiers, a pair of comparators, 4 timers, 2 serial peripherals and the hardware to interface to cap sense inputs. Next to the MCU it includes digital programmable logic in the form of 4 Universal Digital Blocks. Each of them includes 8 macrocells, one 8 bit datapath and two 12 input PLDs. Quite a lot to play with at only 4€.

You can use the PSoC Creator software to program the main chip in the board, but as it doesn't feature any JTAG or equivalent connection you are limited  to programming using a bootloader that is preprogrammed in the chip. That means that you also need to include the bootloader in any user program as it is needed to do any future reprograming of the board. The bootloader, of course, takes a little space on the program memory. This not a big deal, Arduino has been using bootloaders for ages but it is sure a worse solution that the TI Launchpad that include both a two wire Debug link AND a Serial bridge.

I ordered two  CY8CKIT-049-42xx boards. The first thing I do when I receive a development board is to try to program it to check the software. I downloaded the PSoC Creator software and I tried to program a boatloadable PSoC 4 example that is provided for this board.

To program the boad, you need to enter in bootloader mode. To do that you need to press the user button at the same time you insert the board in an available USB socket. One of my boards worked fine and I could program it with no problem. The other, however, wasn't able to enter in bootloader mode so it could not be programmed. I suspected that the problem was the push button so I re soldered its connections. After that, it worked ok. Perhaps there are some quality issues in the manufacture of those boards.

The board is designed to be cut at the serial link between the two chips, just after the serial bridge. It also includes some pins to do proper debugging of the main MCU. To do that, you are suggested to buy a MiniProg3 kit. At 74€ at Farnell it's not a bad option to debug the board.

Board connections

I decided to separate both board sections and to include some connectors to the serial bridge and debug port. That way I can use the board pieces independently of each other. Off course, as I have no MiniProg3 kit, for now I can only program the board using the bootloader.

Soldered Connectors

You need four pins for the serial bridge: Vdd, GND, TX and RX. And you need five for the debug port: Vdd, GND, SWDIO, SWDCLK and RESET. I used one five pin connector and one six pin connector. The unused pin is removed in the male side and blocked in the female side to prevent an incorrect alignment of the pins.

So far so good, I have a cheap development board to play with, but I don't like bootloaders to do developing so my goal is to use the debug port to program the board.

CY8CKIT-042 Pioneer kit

The CY8CKIT-42 is a more featured board that previously described CY8CKIT-049-42XX one. Both feature the very same main chip, a CY8C4245AXI-483, but the rest of the board is quite different. The price is also different as this board cost about 20€.

CY8CKIT-042 Board

A part from more peripherals, like one RGB LED, a cap sense slider and some Arduino connectors, one main difference in this board is that it features full hardware debug. A PSoC 5 programmed as USB debug bridge enables hardware debug on the PSoC 4 CY8C4245AXI-483 chip.

I tested to program this board and do some step by step debugging without any problem. As the cheaper CY8CKIT-049-42XX features the same main chip, I thought about programming it using the debugger in the pioneer kit. Unfortunatelly this is not as easy as in other boards.

Both in the Texas Instruments Launchpad boards and in the ST Discovery boards the flash emulator and the main MCU are connected through jumpers so that you can separate the emulator from the main chip enabling you to use the emulator to develop another board. This is not the case in the pioneer board.

In this board, the PSoC 5 emulator chip is connected to the emulator lines using several zero ohm resistors. Zero ohm resistors R11, R16 and R15 connect the RESET, SWDIO and SWDCLK lines.

PSoC 5 Emulator Zero Ohm link resistors

Those lines connect to a small pitch J6 debug connector and, from that connector, they connect to the PSoC 4 main chip using another set of zero ohm resistors (R34, R32 and R33).

Debug Connector

So we have the three debug lines with the J6 connector in the middle and zero ohm resistors both in the emulator PSoC 5 chip and the emulated PSoC 4 chip.

The solution proposed by Cypress to do debugging in another board using the pioneer PSoC 5 emulator is to desolder the R34, R32 and R33 resistors and use the J6 connector to stablish the debug link.

Pioneer board debug elements

There are two problems associated with the Cypress solution:

• Removing R34, R32 and R33 disables the programming of the PSoC 4 chip included in the board.

• I have no connector that match the 50 mill fine pitch debug connector J6.

Changes in the board

I carried a modification to enable the board to be used as an external debug programmer fro the CY8CKIT-049-42XX board without losing the optin to program the pioneer board PSoC 4 chip.
The idea is to remove all six resistors R11, R16, R15, R34, R32 and R33 and substitute them with a 100 mill standard male connector.

First thing is to locate those resistors, they are between the small PSoC 5 chip and the larger PSoC 4 chip.

Resistors to remove

Then I removed the resistors:

Resistors removed

Then I got a 2x4 100 mill male pin connector and removed the pin in one of the corners:

Standard 100 mil male pin strip

Then I aligned the full three pairs of pins with the landings of the resistors and soldered them in the board leaving the last half-pair pin unconnected.

In the first pair I connect the left side of R11 with the left pin and the right side of R34 with the right pin. For the two other pairs I do the same with R16-R32 and R15-R33. There is no problem if the pads of one resistor are shorted as long as only one resistor is shorted in each pair.

Connector soldered in the board

Side view

If all goes ok, the connector separates the three debug signals SWDIO, SWDCLK and RESET from the emulator to the PSoC 4 main chip. To reenable the connections a jumper can be fitted in each pin pair as is shown on the next figure.

Connector with jumpers

That way I can check that the board can be programmed ok as before.

The pin that was not used in the connector forms half a pair of pins and is designed to provide alignement to the connector so that it cannot be fitted in the wrong orientation. I soldered one wire from this pin to a GND node in the board to provide the needed common reference in the debug link.

Ground connection

Debugging the CY8CKIT-049-42XX board

To debug a CY8CKIT-049-42XX we only need to remove the jumpers route the three debug signals and the common ground between the two boards. That means using the left four pins of the male connector.
If we want to power the debugged board at the same time, we can use the Vdd connection at J5 in the pioneer board. After thinking about it I could have fitted a bigger two row male connector and include the Vdd signal.

Connected boards

You know that the connection is ok if you can enable the debugger in PSoC Creator and detect the chip in the CY8CKIT-049-42XX board.

Chip detected in the debug link

After that I modified a Cypress example program to test the debug functionality and it worked like a charm. Now I can properly debug the dirt cheap CY8CKIT-049-42XX board.

Calibrating the MSP430 DCO

In this article I will give a brief explanation of the MSP340 DCO oscillator and I will provide a program to calibrate it to several frequencies.
This article is a rewrite from a previous article in spanish of my twin spanish blog AIM65.

DCO Description

The MSP340 familly of MCUs feature an internal digitally controlled RC oscillator (DCO). This oscillator generates a frequency that is controlled by three digital values:

• RSELx  (0..15) Select a coarse frequency range
• DCOx   (0..7)   Fine frequency selection for each range
• MODx  (0..31) Frequency modulation between the selected fine value and the next one

The RSELx and DCOx values determine the oscillator frequency as is indicated in the following figure obtained from the MSP430x2xx family guide.

Frequency as function of RSELx and DCOx

The different frequencies you can select for each RSEL value have some overlap. For instance the RSEL=7 DCO=7 frequency could be higher that the one selected with RSEL=8 DCO=0.

The MODx value enables us a finer control of the average frequency. For each 32 clock cycles, (32-MOD) cycles will run at the frequency associated with the selected RSEL and DCO values and the other MOD cycles will run at the frequency associated with the same RSEL but with DCO+1 value.
As DCOx could only be between 0 and 7, the DCO value could not be 7 if we want to use the modulation.

The following figure shows the modulation pattern for different MOD values:

DCO modulation

It is important that the use of modulation introduces some Jitter in the clock signal. This is not important on some applications, but it could be a problem if, for instance, you need a low jitter periodic sampling.

Factory DCO calibration

The frequency associated to each RSEL and DCO value has a high tolerance. If you need an exact operation frequency you need to calibrate the oscillatror. As an example taken from the MSP430G2x21 datasheet, a setting of RSELx = 7, DCOx = 3 and MODx = 0 could yield frequency values between 0,8 MHz and 1,5 MHz. That is, you can have a 0,35 MHz error (23%) respect to the central value of 1,15MHz. 

To calibrate the DCO you must determine the RSEL, DCO and MOD values needed to generate a target frequency. A calibrated DCO gives a more exact frequency than an uncalibrated one, however it can also show some frequency drift in the +/- 6% range due to changes in Vdd and temperature. To minimize drifts, the best way is to calibrate the DCO at the same Vdd and operating temperature that will be used when the circuit is active.

All MSP430 MCUs are factory calibrated at least at 1MHz frequency. The three RSEL, DCO and MOD calibration values are stored on the internal flash memory. To set the calibrated frequency those values must be written to the DCOCTL (DCO and MOD) and BCSCTL1 (RSEL) registers.

There are some problems with the factory calibration values:

• They can only be used at the calibration points availables for the selected MCU. The G2211 has only one calibration value for 1MHz. The G2553 is calibrated for 1, 8 and 16 MHz. If you want to operate at 4MHz in this MCU you need to do the calibration yourself.

• Texas Instruments calibrates at 30ºC and 3V  supply. If you want to operate out of this conditions, a custom calibration could be better than the factory one.

Custom DCO calibration

The calibration procedure needs to check the DCO against a good reference. As the Launchpad board comes with a 32768 Hz quartz, we can use its as reference. You can se an article about this Xtal on another entry of this blog.

You can find on the Internet several references about the calibration procedure like this one or this another. There is also Texas Instruments library to do that.

Most solutions rewrite Section A of the Flash Information Area inside the MCU. That area is used by Texas Instruments to store some calibration data of their MCUs. This area is protected by a special security flag (LOCKA) to prevent an accidental erase of calibration data.

The rewrite of Information Area Section A is dangerous as we could erase not only the DCO calibration data but also the ADC calibration data. Moreover, this area includes a checksum that some applications could try to check. You could recalculate the checksum but you cannot recover the ADC data if it was not saved before erasing it.

Section A is only one of the four information areas included on the MSP430 MCUs. All four areas A, B, C and D have a 64 byte size. Section A is filled at the TI factory but areas B, C and D are empty and free for the user programs. I think that storing the user DCO calibration data could be done on Section B and leave Section A  with factory data.

I selected 9 frequency values for calibration: 500Hz, 1MHz, 2MHz, 4MHZ, 6MHz, 8 MHz, 10MHz, 12MHz and 16 MHz. In the next section I describe the program used for calibration.

DCO Calibration program

main.c

The DCO Calibration program main.c file contains most of the code. It compiles under MSP GCC and should fit in any MSP430 MCU with at least 2kB Flash. Once the program runs and the calibration data is stored in the flash, it can be erased. Any future program could use the stored calibration values.



Two source files are linked to main.c, io430masks.h gives some register mask values and NewDCOCal.h set the flash memory addressed of the calibration data generated by the program.

io430masks.h

NewDCOCal.h

The program is designed to be run on the Launchpad G2 board and  needs the 32768 Hz Xtal to be populated. It also uses the green LED at P1.0, the red LED at P1.6 and the user button at P1.3.

Two MCU pins are also used to check the calibration frequencies:

       P1.4: Square wave at DCO frequency
       P1.5: 256 Hz square wave generated from the 32768 Hz Xtal

When the program starts it checks if there is data in Information Area Section B. If there is any information it goes to the generation frequency mode that I will explain later. If it is empty, the calibration is carried out and the obtained data is stored in Section B jumping next to generating frequency mode.
During calibration, P1.4 shows the generated frequency. Every time a new frequency is selected for calibration the green LED makes a blink. If the calibration for one frequency must be repeated because it is outside the desired tolerance it is indicated with a blink of both green and red LEDs.
  

In frequency generation mode, entered after calibration or upon start if Section B is not empty, the system programs the first calibration frequency (500Hz). Each time the user button at P1.3 is pushed the next frequency is generated. After the last one (16MHz) the system restarts at the first one.

In this mode P1.4 shows the generated frequency and the green LED blinks at a frequency associated to 20 overflows of Timer A0 (20 times the count to 65536 from the DCO frequency).

In case of error the program locks itself with an error code indicated with a number of red LED blinks:

     (1) 32768 Hz clock fails
     (2) Cannot calibrate one frequency

     (4) There is no factory calibration data for 1MHz (It is needed to program the flash)
     (5) Cannot calibrate inside the selected tolerance (5% by default)

If the 32768 Hz clock cannot start at all, the system blocks with the red LED fixed in ON state.

Program operation

In order to do the calibration the Watchdog timer is programmed in timmer mode with about 1,9ms timeout (64 cycles at 32768 Hz) using the Xtal oscillator. Timer A0 is configured in continuous mode using the DCO as input. A capture is generated in A0 each time the Watchdog timer timeouts. We can calculate the DCO frequency from the number of DCO clock cycles between two captures:

DCO Frequency = 512 * Ncycles

To increase the precission the calculation is made averaging 50 captures.

The program starts choosing the RSEL value, then the DCO value just below the target frequency is selected. Finally the frequency is fine tuned using the MOD value.

Conditional compilation

The program uses three defines to configure its compilation.

If the DEBUG define is activated, the program stores the RSEL, DCO and MOD values next to the calibration error at each frequency. That data can be extacted using the debugger.

If the FLASH_OVERRIDE flag is active, the program will rewrite Information Area Section B even if it is not empty upon startup.

If the TEST_MODE is active, all the calibration data will be stored in RAM instead of flash. That way the program operation can be checked without touching the flash memory information areas.

Calibration video

The following video shows the system working in a v1.5 Launchpad board that has the default MSP430G2553 MCU installed.  Next to the board you can see the frequency generated both in an oscilloscope and a multimeter in frequency mode.

Source code is now ebedded (Update at 30/11/2014)

Thanks to Gist the source code is now embedded inside the blog entry.

Source code now in Github (Update at 11/02/2018) 

You can find it in this link:

https://github.com/R6500/MSP430-DCO-Calibration

Soldering the Launchpad Xtal

In this article I will talk about soldering the 32768 Hz quartz Xtal that is provided with the G2 Launchpad.

This article is a rewrite in english of one article in my spanish twin blog Aim65. 

The 32768 Hz Xtal is the basis of a real time clock. In fact 2^15 clock cycles of that device correspond to one second. In the MSP340 familly we can use the Watchdog in timer mode associated to it to generate one interrupt each second.

Launchpad and Xtal bag

This Xtal is included with the Launchpad package but it is not soldered on the board. As  this device uses two MCU pins, you lose two I/O lines when you solder it on the board. It's up to you to decide what is better: a 32768 Xtal or two I/O lines.

The following figure show the position where the Xtal should be soldered.

Xtal Location

This Xtal is tiny and somewhat difficult to solder. The easiest way to proceed is to fix it in place by means of adhesive tape. Beware that the Xtal is not symmetrical. When correctly laid on the board the contacts should touch the soldering pads.

Xtal fixed with adhesive tape

A good soldering iron and a magnifier helps soldering the Xtal.

Xtal soldered on the board

When the Xtal terminals are soldered we can take out the adhesive tape and then we can solder the Xtal body to the pad located below it.

Xtal soldered at the three points

After the Xtal is soldered we should check its correct operation. I have developed a little program to do that. It compiles under MSP-GCC and contain two main files: main.c and io430masks.h.

main.c

io430masks.h

The program tries to start the oscillator associated to the Xtal. If it works ok, the green LED blinks every second. If the oscillator could not start, it lights the red LED.

If the oscillator cannot start we must first check the soldering.

The oscillator is quite sensible to any interference. The oscillator pins are connected to the J2 header as they can also be used for I/O. This connection includes two zero Ohm resistors in the path. To minimize any interference those lines can be disconnected desoldering those resistors.

Resistors removed

Alternative to soldering the Xtal

If you don't want to mess with the board or you don't want to permanently eliminate two I/O lines you can connect a Xtla to the J2 lines associated to the oscillator.
That can be done using the Xtal provided with the Launchpad but its size makes it a little complex. Moreover 32768 Xtals are cheap and easy to obtain. It is important, however, to buy ones designed to operate with 12,5pF or 6pF capacitors. As the MCU includes those capacitor options inside you don't need to add them using discrete components.
This is the Xtal I have bought at Farnell, for instance:

Xtal soldered to a female header

I have soldered it to a two pin female header to be easily connected to the oscillator J2 pins.

Xtal at J2

Connecting the Xtal at J2 increase its wire lenght and could give some interferences. The proper solution is to solder it on board if possible.

With the Xtal mounted on the board its easy to develop any application that should keep a real time clock.

MSP340 Launchpad Fet

In order to do In System Programming (ISP) you usually need a Flash Emulator Tool (FET). For the Texas instruments MSP340 family you can buy the one that TI sells for their MCUs:

Official TI MSP340 FET

That costs about 100$ and it isn't too much if you program MCUs for a living. It can work with supplies from 1.8V to 3.6V and do program/debug using JTAG or Spy-By-Wire (2 Wire) interfaces.

For the hacker that buys their own tools there are cheaper solutions. You can find several references on Internet about people that have used the MSP430 Launchpad to do ISP programming. This Launchpad board is designed to program MSP430 MCUs of the "G" value line in dip packages using an included 20 pin socket. As all the signals needed to do Spy-By-Wire are available so you can use this board to program MCUs located in another board as long as you route the needed signals: TDIO, TCK and the reference GND to the proper pins of the MCU to program.

This article explains a FET implementation using the TI Launchpad. As this board provides also a serial TX/RX communication using the PC USB connection. It will also be implemented in the FET.

Features

• Two Wire Spy-By-Wire for the MSP430 family
• Serial TX and RX communication at 3.6V level

Limitations and Disclaimer

The FET will inherit all the limitations related to the use of the TI Launchpad as a FET device.

• Can only use Spy-By-Wire, no full JTAG is available
• It can only work with and provide 3.6V

The second limitation could be important. As the Launchpad works at a fixed 3.6V supply, the provided Vcc and the signaling is at 3.6V. As long as the board you communicate with is at about 3.6V all will be ok. 

As 3.6V is the maximum operating voltage in the MSP430 you cannot connect the FET to a board that operates the MCU at a greater voltage. In the case of connecting to a board that uses a lower voltage, let's say 2.5V, you could power the board without using the FET, but the signaling from the FET to the board will be at 3.6V and that could be above the Absolute Maximum Ratings from the MCU. Adding level shifters is out of the goals of this project so I recommend using this FET only when the board is powered between 3.3V and 3.6V in order to guarantee that the Maximum Ratings are not exceeded.

If the connected board should work at less than 3.3V I recommend to power it at 3.6V from the FET during the programming and debugging and powering it at it's own lower voltage when it is disconnected from the FET.

Off course this document is only a documentation of something I have done for myself and there are no provided guarantees that it will suit your own needs or that it won't blow-up your home. Yoy have been warned.

Launchpad Signals and project schematic

The signals needed to program a MSP430 chip and provide Serial communication are mainly at the J3 connector that links the emulator upper side of the board with the target MCU lower side. As we won't use the lower part, we will take out all the five jumpers in J3.

Launchpad connectors used

The signals used will be:

• SBWTDIO: Two wire data / nRESET
• SBWTCK: Two wire clock
• VCC: 3.6V supply generated from the USB line using a regulator
• RXD: Serial from MCU to the PC
• TXD: Serial from the PC to the MCU

We will also need a common GND node. This one is not available at J3, so we will take it from pin 20 at J2.

The connector J1 is not needed, but as the Launchpad has no mounting holes, it will be used to provide physical support.

Project Schematic

The above schematic shows all the needed connections. In the Launchpad we will use J2 and J3 to provide the needed signals. Those signals will be routed to a 2x4 male connector that will be used to do ISP on the target MCU. I have removed one pin in the connector (marked with X) to be able to develop cables that can only be connected in the right way and not in the 180 degree rotation position.
A LED to check that the Launchpad is operating and a push button to force a RESET on the target MCU complete the schematic.

Construction

To build the project I have selected a box that is just over the Launchad board size.

Project Box

All the connections will be done on a perf board. In order to mount it on the box four M3 thread 10mm spacers are fitted inside the box.

Box with fittex M3 spacers

The board is cut to the box size and it has been milled to leave space to the thread posts that are in each corner of the box. Four holes match the four spacers in the box.

Perf Board

As I have commented, the Launchpad board has no mounting holes, so I will put it over the perf board upsidedown. That means that the connections on the board will be mirrored respect to the Launchpad ones as seen from above.

Board Distribution

I have used three connectors, one female 2x5 to match J3 and two females 2x7 that connect to J1 and J2. I know that J1 and J2 are 1x10 male, but I had those 2x7 connector lying arround and as I only need to connect one pin at J2 that's ok for this project.
The LED  will be connected to the board with a pair of wires. To make things cleaner I have added a 2 pin male connector in the board to connect it.

The following figure shows the populated perf board with all components. The LED  that will connect to the two pin male connector is also shown .

Populated perf board

To make the necessary connection I have used WMS (Wire Mess Routing). As the connections are easy this is ok for this project.

Wire mess under the board

The board is mounted inside the box and it is secured with four M3 screws.
To connect the Launchpad board all five J3 jumpers and the DIP MCU must be removed.

Launchpad Board without MCU or J3 jumpers

The Launchpad board is mounted upsidedown over the perf board and the LED is fitted in a 5mm hole and connected to the board.

Four holes are made on the box. One for the Launchpad USB connector,

two for the ISP connector and the LED,

and the last one for the RESET button. This one is missaligned, I know.

Four feet bumps, one on each corner complete the box and makes it stable over a table.

To end the build I have added a picture over the box with the ISP connector pinout.

 Echo Blink Test Program

To test the FET we need a program to load in a MCU using ISP. The developed program blinks a LED so we can see that the program has been corretly transfered to the MCU.
The program also provides an echo functionality using the serial port. Each character received from RX is converted to uppercase (if it was between 'a' and 'z') and then it is echoed to TX. That way we can also test the serial communication using the same program.

I have three toolchains to work with the MSP340 familly:

• MSPGCC eclipse based IDE that I configured myself
• Code Composer Studio that is free for the Launchpad Use or below 16kB
• Energia

The last one, Energia, is interesting because it provides an Arduino like IDE for the MSP430 familly. If you don't know Energia and like Arduino, chek it out. One important difference with Arduino is that Arduino boards are programmed using a bootloader, so you need a resident program in the MCU. Energia, uses Spy-By-Wire, not serial, to do the programming so it doesn't need a bootloader. This makes easy to program any compatible MSP430 chip you have bought.

Energia, in the same way that the Arduino IDE don't provide hardware debug functionalities. As the FET can be used to do hardware debugging on the target MCU, using Energia is not the most featured solution, but sure it is the easier to get working. So, I developed the Echo Blink program as an Energia sketch.

The Echo Blink sketch is provided in this link. But you can also see it here:



The program just blinks a led on P1.0 (pin 2 on MSP430G2553) changing its state each 200ms. During the 200ms wait between changes, the RX line (FET TX) is tested for incoming chars each millisecond and the characters are changed to uppercase if they were in lowercase and echoed to TX (FET RX). If no character is echoed during each 200ms wait, a '.' char is sent to TX. That way TX can be tested alone.

Simple ISP schematic

You can program a system outside of the Launchpad board using the FET. At a minimum, it needs to have the needed connections between the FET and the MCU: GND, TCK and TDIO. The Reset line that is shared with TDIO must not be connected directly to Vdd. A 47k resistor to Vdd and a 1nF or 2.2nF to ground works ok. You can also add a reset button if needed in this line.
The following figure shows a simple system to be ISP programmed.

Basic ISP system based on MSP430G2553

Aside from the described ISP and RESET connections there is a 100nF decoupling cap. The serial TX and RX are also included but they are not needed to programming.

System Test

To test the system I have connected it to and a PC and a MSP430 G 2553 and loaded the Echo Blink program.

System running, only tested programming on this test

I have also connected the system to a 28 pin TSSOP MCU, using a SMD to DIL adaptation board, and it also works ok.

Test of a MSP430 G 2553 in TSSOP 28 package

All in all I'm quite satisfied with this build. It eases programming a MSP430 MCU using a launchpad board.

Echo Link Program Running

Addition at 7/10/2014: It seems that someone has made the same upsidedown FET configuration before. It don't surprise me. You can find it at this link. (It's in Hungarian)

Update at 30/11/2014: Now the EchoBlink.ino sketch is embedded in the blog using Gist

STM32 Nucleo Boards

I have just received two nucleo boards: the L152RE and the F401RE. This is my first impression.

The Nucleo boards are the last entry level boards in the STM32 family.

STM32 Nucleo advertising

In the last years ST has provided the fantastic Discovery boards. Those boards, specially the STM32F3, STM32F4, STM32F401 and STM32F429 pack a lot of power for their price. Unfortunately they are not easy on the beginners. Of course there are projects like ChibiStudio or CoIDE that ease the programming of these boards but they are not as easy as Arduinos, for instance.

But that changes with the Nucleo boards. Those boards are mbed enabled. Mbed is a development platform for ARM microcontrollers. It started with the ARM Embed board based on NXP LPC microcontrollers. What is special about this platform is that it is web based. You don't need to install any toolchain in the computer and the source files are available everywhere. And, as in the Arduino case, you get libraries for all the board peripherals. Off course, a web based compiler is not the solution for everyone. For instance you cannot work offline.

mbed web compiler

You write the code from scratch or from one of the examples available. Hit the compile button and a binary file is generated that you can directly drop on the mbed board that shows on the PC as a mass storage drive. Quite easy.

The Nucleo F401RE Board

The nucleo boards are not the only mbed boards. They are only the last ones in the mbed world but are well positioned next to several cheap boards from Frescale that are mbed enabled too and range from the basic 32KB Flash FRDM-KL05Z to the 1MB Flash Ethernet enabled FRDM-K64F.

The original LPC mbed boards are not so well positioned in price or specs.

In this article I will talk about the F401RE Board that is the best specified nucleo board available. I don't have first hand experience on the Freescale mbed enabled boards buy they seem to be very interesting boards too.

Nucleo F401RE board

The Nucleo F401RE board includes an ARM Cortex M4 STM32F401RET6 microcontroller with 512KB of flash memory. As all nucleo boards are equally priced I see little point in buying any other nucleo board unless you have very special requirements.

In the above figure I have encircled the two clock crystal empty slots. Some figures show them populated but you must be aware that the they are not in the board. You will normally get the clock from the upper side of the board that includes the USB connector but if you separate both board pieces you will have no crystal clock for the board. And, of course, if you need a 32kHz clock for the real time clock you would need to solder it yourself.

The nucleo boards are compatible with the now "standard" Arduino headers.

F401RE Arduino headers

If, as in my case, you don't mind about Arduino compatibility you can use the dual row Morpho headers that include more signals that the Arduino headers and don't include the damm non 100 mil pitch space of the right arduino headers.

F401RE Morpho headers

This is a very capable board. The ARM Cortex M4 processor includes a FPU that speeds any 32bit floating point operation. As an example I have tested that the board can calculate 40000 times the square root of a float quotient in only 25ms. Its not as fast as a STM32F4 Discovery board but is a quite good spec for a board so cheap and easy to program.

All in all I'm quite pleased with this board. Packs a lot of power for its price and its very easy to program.
In the future I plan to try to program it using more traditional development tools under eclipse but for now mbed is working quite well. In fact I like this environment more that the Arduino one.

Intel Galileo. What will I make?

Some time ago I applied for the Intel Galileo university program and I was given ten Intel Galileo boards to be used on education projects. I supposed that the first I should do is learn to use the board before giving it to my students. This is the first blog entry about this board.

Intel Galileo Board Box

The Expectation

The Intel Galileo board promises a lot. It is an Arduino compatible board that uses a 400MHz 32 bit Intel® Quark System on a Chip (SoC) X1000 Processor. That makes it the fastest Arduino Board in the market while we wait for the Arduino Tre upcoming board.

Intel Galileo Board

The Galileo board includes a lot of functionality:

• Ethernet LAN RJ45 socket
• RS-232 COM 3.5mm Jack
• USB Client Socket
• USB Host Socket
• SD Slot
• Mini PCIe connector for WLAN Card
• One SPI port
• One I2C port

And, of course, the full Arduino UNO headers with 14 Digital lines (6 with PWM functionality) and 6 analog lines. The full board specification can be found in this link.


The board can be programmed using a special Arduino IDE with version 1.5.3. The IDE makes easy to program the board as any other Arduino board.

That all sounds good , ok?
Well not everything is so good in this board.

The Reality

The main problem about this board is in the GPIO implementation.
Intel decided to use a Cypress CY8C9540A I/O expander to implement most of the I/O functionality.

The Cypress CY8C9520A Expander Chip

The selected I/O expander is quite powerful. It gives 40 GPIO lines and 8 of them can generate PWM. I suspect that Intel selected this chip in order to mimic the standard Arduino I/O functionality. The problem is the I2C link that communicates this I/O expander with the Quark CPU. It operates at a only 100kHz. That means that the in practical terms the maximum GPIO frequency is 230Hz for most of the I/O pins.

Two lines (IO2 and IO3) that are normally routed through the I/O expander can be alternatively routed directly to the SoC chip and thus can operate at a much higher frequency. But only those two pins can benefit from high speed operation.

The analog readings are provided by an external  AD7298 ADC but at least this device connects at 4MHz with the SoC chip using a SPI interface.

AD7298 ADC (to the right)

The catch is that most Arduino compatible I/O lines, analog included, are routed trough TS5A23159 multiplexers that are controlled by the outputs of the I/O expander controlled by the slow 100kHz I2C interface. So changing from digital to analog mode on a pin is quite slow.

The final problem is that the SoC chip don't run directly the Arduino sketches. The SoC runs under Linux and the running sketch is one process in the myriad of processes of the Linux operating system. As Linux is not real time you cannot guarantee a deterministic timing on the sketches. If the operating system happens to be under high load you can expect a lot of jitter on the sketches.

All in all, the Galileo Board includes a power hungry (it cannot run on USB only) 400MHz Quark SoC but a lousy ATmega328 at 16MHz on an Arduino UNO runs circles around it in raw GPIO bandwidth.

Arduino UNO

So, what will I make?

In the end the Galileo Board delivers less than I expected due to the small I/O bandwidth that the 100kHz I2C port expander provides. The Linux operating system also don't help to obtain a deterministic reaction time. As a conclusion the Galileo Board is not a good board for fast real time operation. Better use a normal Arduino board or, better yet, a STM32 Discovery board for fast I/O operation.

Following the Arduino path

If you want, however, an Arduino compatible board that includes support for Ethernet, SD card storage and a real time clock and provides a lot of RAM and ROM memory, this is a very capable board if you don't mind the the slow GPIO bandwidth.

I use the Arduino Leonardo board in a mixed analog-digital lab course for students without the proper programming foundations to use a more capable board.

Arduino Leonardo Board

For applications that need more memory and speed I use the PIC32 Pinguino board. For the price of a Leonardo you get a board that features much more memory and speed and includes several goodies as a SD card slot and a 32kHz clock. I don't use this board as the main one because the Leonardo is better supported by the Arduino community.

PIC32 Pinguino Board

Now I have also the Galileo. I plan to use the Galileo in Arduino projects that need a lot of memory or network connectivity and don't need fast GPIO operation.

Following the Linux path

I am more interested, however, in the Galileo as a Linux board, not as an Arduino one. For some kind of projects I'm interested in controlling the board from Linux eliminating any Arduino IDE operation. That puts this board next to the Raspberry Pi and the BeagleBone / BeagleBone Black boards. 

BeagleBone Board

Raspberry Pi Model B

Both of the Raspberry Pi and BeagleBone boards are faster. Also both the Raspberry Pi and the BeagleBone Black provide a video output that the Galileo lacks. So the Galileo will only be useful for embedded operation not as a desktop computer substitute.

Compared with the Raspberry Pi the Galileo has some strong points:

• One USB client that can work as a serial over USB terminal
• 14 Digital lines and 6 Analog lines with both 3.3V and 5V functionality
• A RS-232 level Serial
• A battery backed RTC clock  
• Arduino Shield Compatibility
• Four mounting holes that make it easier to use without a case.

Off course the Raspberry Pi has also some strong points:

• Faster operation
• Much more capable Linux distribution
• Video and audio output
• Camera and LCD connectors
• Cheaper price

It's a pity that the Raspberry Pi don't provide a USB client to enable a serial over USB console. For headless operation that could be very handy. The lack of proper mounting holes is also a problem.

For desktop Linux use nothing beats the Raspberry Pi in its price range but it shows that embedded operation was not a priority in its design.

For embedded Linux operation the BeagleBone is my first option. Both the BeagleBone and the Galileo feature digital and analog I/O although the BeagleBone with its GPMC bus features several orders of magnitude higher bandwidth. Both boards feature Ethernet and a serial over USB console. Both boards feature also a USB host socket. In general, however, the BeagleBone is more powerful. It uses a better Linux distribution, has higher clock frequency, consumes less power, and has more I/O lines and bandwidth. The only thing that the Galileo has and the BeagleBone lacks is the battery backed real time clock and Arduino Shield compatibility.

I plan to use the Galileo boards for Linux projects that don't need all the BeagleBone power. As this board includes in the SD card image a Python interpreter and no C compiler I will start using it in Python.

Closing Comments

That's all for now. In the end the Galileo is a quite capable Linux board but it could have been much better if the designers had opted for a higher bandwidth I/O solution. That's a pity because that positions this board in a very bad place against the BeagleBone Black. It's only strong point is the Arduino shield compatibility but I don't really care about that.

I know that it is difficult for Inter to fight against ARM but those kinds of design decisions don't help at all.
Off course I will use for teaching projects the ten Galileo boards I have been given but I'm not sure I would opt for these boards if I needed to buy them myself.

Testing the AD5697R DAC

Yesterday I tested an interesting DAC: the AD5697R. This an interesting 12 bit dual channel Digital to Analog Converter (DAC). I plan to use it on a project where it will susbstitute some operational fixed voltages. 

Using a DAC instead of a potentiometers make those voltages adjustables by the microcontroller that manages all the system. Moreover, as the DAC features an internal reference the voltage values are independent on power supply variations. 

Unfortunately, as is more and more habitual this days the DAC only comes in SMD packages and they are not board friendly at all. This 16 pin device comes in the 3mm x 3mm Lead Frame Chip Scale Package (LFCSP) package and in the 5mm x 4.4mm Thin Shrink Small Outline Package (TSSOP) package. That's tinny!

Adpating the chip to protoboard use

I selected the 16 TSSOP package as it's easier to solder although it features a 0.65 pin pitch that is about 1/4of the standard 2.50 (100 mil) DIP pitch. To test it on a protoboard I used an SMD adapter. The following figure shows the adapter I used before soldering the chip. The image also serves to show the pitch difference between TSSOP and 100 mil DIP.

TSSOP16 Adapter

As is normally the case, the adapter costs more than the DAC chip itself.

This adapter, however, has one problem: It uses dual rows of pins at either side of the chip. That's bad for a protoboard as you will short odd and even pins.

The solution was to extend the adapter after I soldered the chip:

Adapter extension

Using the extension half of the 100mil pitch pins are soldered to the original adapter and the other half to the extension.

Test circuit

So far so good. Time to test the chip.

In order to test the chip I used the F3 Gizmo to send the I2C commands the chip needs to operate.

Test circuit for the DAC

The circuit only needs four main wires: 3V supply, ground and the I2C SDA and SCL lines. A0 and A1 are connected to ground although this is not shown in the above schematic.

Test circuit on the protoboard

Test of the DAC

Once the test circuit is mounted it's time to test the DAC by sending some I2C commands.

The 7 bit I2C address for the DAC is

0 0 0 | 1 1 A1 A0

As A1=A0=0 the address will be:

000 1100 = 0xC

Using the F3 Gizmo ISCAN word whe can check that the I2C channel is operational:

     ISCAN

     0xC

To send data to the DAC we must send 3 Bytes to it's I2C address.

The first Byte indicates the command and the channel.

The 4 MSBs are the command. The command I tried is:

0011 (3h) Write to and update DAC channel n

This command directly writes a binnary data to one or both DAC channels.

The 4 LSBs of the first Byte selects the channel to adress:

    0001 (1h) DAC A
    1000 (8h) DAC B
    1001 (9h) DAC A and DAC B

The two following Bytes to send are the data to send to the DAC. As two bytes are 16 bits and the DAC channels are 12 bits only, the last 4 LSBs bits are discarded.

The DAC uses an internal 2.5V bandgap reference. The full scale (FFFh code) should be 1 LSB below the reference for the selected GAIN=1. If the GAIN pin was at VDD the selected GAIN would be 2 and the full scale value would be one LSB below 5V.

In order to set the A channel to the maximum value we can must send the following data:

  Command: 3h

  DAC addressed: 1h

  Code to send: FFFh
  Last dummy nibble: 0h

We can use the following F3 Gizmo command in order to send the data:

   0xC 0x31 0xFF 0xF0 3 0 I2CT

As a result the output goes to 2.5V as expected.

To set any other value we must compute the 12 bit value. For instance, to set the output to 1V we must use the code:

   code =4096 * 1 / 2.5 = 1638 = 666h

Using the F3 Gizmo that means sending the following command:

   0xC 0x31 0x66 0x60 3 0 I2CT

As you can see from the multimeter reading the response is quite good.

Measuring the response to code 0x666

Having the DAC an internal reference makes very easy to generate exact absolute output values.

The test was a success. Now I can test the rest of the I2C functionality before deploying the DAC in the project.