Value Line series easy DCO setting library

[NatureTM 100]

The thing I just posted took like 5 sec.

[simpleavr 399]

well, i look at the assembly code and the approach is the same except

 

           jz      ExitNoError             ; if r12 = r10, DCO set exactly
           cmp.w   #0xFFFF, r10            ; DCO can be off by 1 for a tolerance
           jeq     ExitNoError

 

there is no tolerance in the c code, and if it does not get the exact value, it will go "too-slow" adjust, and "too-fast" adjust for many hours until there is a change of temperature that triggers a slight clock tick.

 

anyway, i was curious on the accuracy of this calibration approach, mine shows the result value is a bit higher than expected, and i was wondering if anyone else tried and think so too. if someone got a frequency counter or some other equipment to check against.

[simpleavr 399]

Do they really do this when they manufacture the chips? individually calibrate each chip. Wow!

i look at the G2231 and it got the same spec as a F2012, i would say they calibrate less (which costs them to do) and can sell it for less as "value line".

 

SimpleAVR, I have a TI Rep office close to my place. I can forward your questions to him.

nay, it's just curiosity to see how things works.

[jbremnant 17]

Interesting discussions. I am learning a lot just by reading your posts!

The DCO is a more complex internal clock source than I thought. In avr's I only had to fiddle with fuse settings.

 

TI must have some recommended calibration values for higher frequencies msp430g2xxx series?

Or is this calibration value idiosyncratic and needs to be adjusted on a case by case basis?

[simpleavr 399]

The DCO is a more complex internal clock source than I thought. In avr's I only had to fiddle with fuse settings.

 

and it's more flexible than avr, as u can go fast and slow at will (or at runtime). i kind of like it more than the avr now.

[NatureTM 100]

I sort of tested the speed of the lib I posted. I only have a 20MHZ scope, so checking 16MHz gets aliased. The dco lib I posted had a MCLK/10 output that I was able to check, and it seemed correct. If you look at the DCO_Library.h file, you can see the delta values and have a better idea of nominal speed. They're just a little off.

[simpleavr 399]

thanks naturetm, that's good to know. both the assembly and c code used the same strategy but the implementation detail is different. i am sure the assembly code is more accurate as there's always less impact from the compiler (and all various compiler switches).

 

my taking on the c code is more out of curiosity. i am now thinking the higher values may be caused by the fact that the calibration is done in a continuous mode. it is adjusting the DCO values w/o stopping either timers to do a clean start. and the next capture count is taken by subtracting the last capture. this may have impacted the result.

 

will post again when i find out more.

[NatureTM 100]

Ok cool. I just used the assembly for the reason you stated. I was curious about that C function too. I'm interested to know what you find.

[jbremnant 17]

I have an idea.

 

Once we can get good calibration values off the software (asm or C) and verify that they produce accurate enough clock at desired frequencies, we should create a command line utility (in linux) to store these into reserved areas in the chip. Unfortunately, I don't have the proper equipment to verify the frequencies... (maybe I can do this from logic analyzer?)

 

simpleavr and NatureTM has been showing us very good progress, and I'll be happy to volunteer for whipping up cmdline utility for these value line chips. The task I have in mind:

- shell code that takes pre-compiled .elf, or compile the src on-demand if msp430-gcc exists.

- the .elf will simply attempt to generate calibration values and write to proper flash area.

- using mspdebug 1) flash the target chip with .elf, 2) run code, 3) inspect desired mem locations to verify calibration values, 4) once verified, erase the chip. EDIT: maybe I can take the precomputed calibration values and write it directly to the chip without having to flash the necessary firmware to do it.

 

What do you guys think?

[NatureTM 100]

I already am able to compute the values and write to flash. I think they're pretty close. I was having trouble getting the linker to recognize them in my code, however. I'll probably take a closer look this evening.

[NatureTM 100]

So I've written the calibration constants to flash, and then re-flashed with my TV Out program that is very timing dependent and it works with the flashed 16MHZ calibration! You'll need to use modified linker and header files so the compiler knows about the constants. I should have something more formal soon.

 

EDIT: I created a new thread for flashing the constants:

http://www.43oh.com/forum/viewtopic.php?f=10&t=239

[GeekDoc 226]

So I've written the calibration constants to flash, and then re-flashed with my TV Out program that is very timing dependent and it works with the flashed 16MHZ calibration!

So, your TV Out works with the internal oscillator now? No external crystal? How cool is that!?

[simpleavr 399]

The task I have in mind:

- shell code that takes pre-compiled .elf, or compile the src on-demand if msp430-gcc exists.

- the .elf will simply attempt to generate calibration values and write to proper flash area.

- using mspdebug 1) flash the target chip with .elf, 2) run code, 3) inspect desired mem locations to verify calibration values, 4) once verified, erase the chip. EDIT: maybe I can take the precomputed calibration values and write it directly to the chip without having to flash the necessary firmware to do it.

 

What do you guys think?

 

i say when it's done we create a thread w/ simple descriptions and instructions on the code area, to allow members to

. grab source, compile, flash and have clock calibrated.

. elf binary and mspdebug instructions for whoever don't want to compile.

. ti / iar binary and instructions for flash only.

. simple write-up on why and how to use calibrate clock values.

 

there is really not much to it in my view to create wrappers for the job, just step by step instructions should do. the hard(er) part is what's happening in this thread. i.e. validate / adopt the F series calibration examples to G series and develop how-tos for them.

[simpleavr 399]

NatureTM had created a clean and easy to follow instruction here,

 

viewtopic.php?f=10&t=239

 

i think the format is good and members can easily find and use such resources. may be bluebash should make some of these code snippets "sticky" in the future for easy discovery.

[jbremnant 17]

@simpleavr

I had the chance to try out your C calibration derived from msp430x20xx_dco_flashcal.c.

I did this in linux (Ubuntu). It seems to have worked and I got wrote these values in the flash.

Previously, mem location from 0x10f8 was all 0xff's until 0x10FE (location for 1MHz constants).

 

mspdebug rf2500 "dis 0x10F8 8"
...
Device: MSP430G2231
Code memory starts at 0xf800
Number of breakpoints: 1
   010f8: 91 8f 99 8e 88 8d         SUB     0x8e99(R15), 0x8d88(SP)
   010fe: 40 87                          SUB.B   R7,      PC

 

I need to see if the asm lib produces similar results. I did have trouble compiling the .asm code in to an object file though.

What is the necessary msp430-gcc command to include .asm (.s) code compiled along with your other C source in linux?