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