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.
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 |
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.
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.
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 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
If the 32768 Hz clock cannot start at all, the system blocks with the red LED fixed in ON state.
To increase the precission the calculation is made averaging 50 captures.
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.
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)
(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
No comments:
Post a Comment