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.