• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 1031 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430G2553: Clock calibration missing

George Weickhardt25
Prodigy 100 points
Part Number: MSP430G2553
I received a prototype from our manufacturer for a battery charger I have been working on. As far as I can tell the hardware is identical to my version.
When running my code that uses a 16MHz system clock, my board has no issue, but it appears that the manufacturers board does not have clock calibration data: ( CALBC1_16MHZ = 0xFF )
I confirmed that my CCS is configured to only erase main memory.
In my code I could not find any #defines for CALBC1_16MHZ or CALDCO_16MHZ in msp430g2553.h
only this:
Inline image 1
I saw that -l msp430g2553.cmd  Is in my lnk_msp430g2553.cmd but could not find the .msp430g2553.cmd file in the directory to check whats in it.
Can this only be calibrated with external reference? 
  • 0
    Guru 88700 points
    If you're using the BSL to program your boards, it's not difficult to make a mistake which will cause it to erase the clock calibration in InfoA.

    The constant isn't in the linker (.cmd) file, it comes from the factory. TI example msp430g2xx3_dco_flashcal.c will compute and store (into InfoA) new constants, based on an external 32kHz crystal (really just ACLK, presuming it's running at 32kHz).

    Without some sort of external "known good" clock source, it's not obvious how one would re-calibrate the DCO. I've had limited success with "borrowing" constants from other chips in the same batch -- sorta-adequate for the lab, not for products.
  • 0 in reply to Bruce McKenney47378
    Prodigy 100 points

    Thanks for the reply Bruce.

    If we have TI program our chips before they are sent to manufacturer, we should be able to avoid this issue then?

  • 0 in reply to George Weickhardt25
    Guru 88700 points
    I suppose so. (I didn't know TI offered that service.) If anyone knows the tricks, they do.

    Do you have (access to) Any spare pins on your target MCU? flashcal.c doesn't do magic (though it Is a nifty trick) -- it sets up a software FLL based on timer Capture of the ACLK wave. If you have a timer pin free, you could do a similar thing by connecting an external clock (signal generator) to it. Even with a plain old GPIO you could approximate Capture using a pin interrupt and a free-running timer. Just a thought.
  • 0 in reply to Bruce McKenney47378
    TI__Intellectual 1370 points

    Hi George,

    The chip should already have the calibration constants for the DCO stored in Flash from whatever supplier you get the chips themselves. As Bruce said, if the BSL is used to load the software through a warm start (the device jumps immediately to the program after the BSL without resetting the device) the device can remain in an unlocked state causing something to erroneously erase the entire Flash including the calibration data. It is recommended to load the program through the BSL with a cold start to prevent mistakenly erasing the calibration constants. More details can be found in the MSP430 FLash Device BSL User's Guide.

    Also as Bruce said, if the calibration constants are erased, they can be re-initialized using msp430g2xx3_dco_flashcal.c with a clock reference.

    Are you having the boards initially programmed by your board manufacturer. Can you check with them that they are initially programming the chips through the BSL cold start?

    Thanks,

    Ryan

  • 0 in reply to Ryan Meredith
    Guru 88700 points
    Cold start aside, I guess I would state it differently: If the user enters an incorrect password -- quite easy to do by accident(*) -- the BSL will issue a mass erase with LOCKA cleared, i.e. erasing the calibration constants. This appears to be seen as a feature, not an error. I suppose there was a concern that someone might have stored confidential information in InfoA. [Ref: SLAU319O Sec 2.4.4.4 ("NOTE"), Sec 2.7] I "demonstrated" this a number of times when I was putting together some G2553 BSL procedures a few years ago.

    (*)Since the password is just a section of the interrupt vectors, in order to load new code with the BSL one in general needs to know what code is already loaded.
  • 0 in reply to Bruce McKenney47378
    Genius 4350 points
    Yeah, I'm gonna go with error, not feature. Just my 2 cents. In any case, all the more reason to store that null word at 0xFFDE in *ALL* G2553 code.
  • 0 in reply to George Weickhardt25
    TI__Intellectual 1370 points
    Hi George,

    Were you able to find more information about how the parts are being programmed initially to see if that might be causing the calibration constants to be erased?

    Thanks,
    Ryan
  • 0 in reply to Ryan Meredith
    Prodigy 100 points
    Hi Ryan,

    Yeah they did not take precautions to do BSL cold start so it could definitely be the cause. Waiting to see if it is fixed on the next batch.
    I will also add the Null to FFDE. Thanks for the advice.

**Attention** This is a public forum