Jump to content
43oh

Value Line series easy DCO setting library


Recommended Posts

  • Replies 48
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Here's an existing TI lib I modified to work with the Value Line series and CCS.   Since the G series doesn't come with factory-calibrated DCO settings, I wanted an easy way to set the MCLK to 16MHz

if u dump out the stock flash portion where the calibrated values are defined.   (mspdebug) dis 0x10f0 010f0: ff ff ff ff AND.B @R15+, 0xffff(R15) 010f4: ff ff ff ff

it was the crystal all along.   the c example msp430x20xx_dco_flashcal.c (from slau80) has been working all right.   i finally solder a 32khz crystal onto my launchpad, result became better but st

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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?

Link to post
Share on other sites

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

Link to post
Share on other sites
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!? :D

Link to post
Share on other sites

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.

Link to post
Share on other sites

@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?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...