• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 79 subscribers
  • Views 935 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430G2453: Auto-Speed calibration Fault

Viktorija Cecil
Mastermind 18501 points

Part Number: MSP430G2453

I expect to see RSELx=15 after loading the factory calibration for 16Mhz operation with s DCOCTL value somewhere mid-range.  Found two micros with RSELx=14 and DCOCTL near maximum value to achieve 16MHz.  I guess that’s ok if we are not calibrating further – but we are now and hitting the maximum value on DCOCTL.

I think we have the solution (see below) but I would like to know what range of factory cal I can expect and if RSELx=14 is intentional. (looks like a process bug to me).

The system uses 60Hz line frequency sampled over 30 seconds to adjust the microcontroller clock. The process is continuous and will automatically adjust for DCO source changes due to temperature.

Register RSELx for this device select the base frequency range. Typically the value of RSELx is 15.

Registers DCOx and MODx are calibrated values that fine tune the operating frequency inside the range defined by RSELx

RSELx in BCSCTL1, DCO and MODx in DCOCTL are loaded from the manufacturers pre-programed calibration data space at power up. Every 30 seconds of time the captured 60Hz frequency is compared with ideal values and the DCOCTL register is incremented or decremented to bring the clock frequency in line.

 

Typical values at power up:

RSELx = 0x0F (according to the data sheet this should always be 0x0F)

DCOCTL = 0xAA

 

Value of the faulting sample:

RSELx = 0x0E

DCOCTL = 0xE0

As the controller heats up the value of DCOCTL must be increased to compensate for the clock drift due to temperature.   In the faulted unit DCOCTL was incremented until it wrapped around to 0x00 causing the clock and motor speed to drop. The lower bits of DCOCTL have no effect on the clock frequency above a value of 0xE0 so the code kept adjusting until the register wrapped around to 0.

Simple limits have now been placed on the value of DCOCTL to prevent wrap-around. However that does not solve the adjustment problem. The faulted motor now will loose a small amount of speed as the control heats because the value of DCOCTL is at maximum.

Solution:

Code has been added to detect when RESEL value is 14 and when the DCOCTL value is maxed out (0xE0). If this case is persistent for 60 seconds the software writes RSEL=15 and resets DCOCTL to the mid range value. Continuous calibration then proceeds as normal.

Thanks

Viktorija

  • 0
    TI__Mastermind 49692 points
    Hello Viktorija,

    I suspect that this behavior is caused by the BCL12 errata. I would recommend implementing the workarounds mentioned in the erratasheet for this errata.

    Regards,

    James

    MSP Customer Applications
  • 0 in reply to James Evans
    TI__Mastermind 18501 points

    James,

    That is not what customer is seeing.

    They see calibration values that are at the very end of the adjustment range from the factory.

    Let me know what you think.

    Thanks

    Viktorija

  • 0
    TI__Mastermind 49692 points

    Viktorija Cecil said:

    I expect to see RSELx=15 after loading the factory calibration for 16Mhz operation with s DCOCTL value somewhere mid-range.  Found two micros with RSELx=14 and DCOCTL near maximum value to achieve 16MHz.  I guess that’s ok if we are not calibrating further – but we are now and hitting the maximum value on DCOCTL.

    I think we have the solution (see below) but I would like to know what range of factory cal I can expect and if RSELx=14 is intentional. (looks like a process bug to me).

    According to page 14 in the datasheet, "all ranges selected by RSELx overlap with the next range, RSELx + 1". So, RSELx = 14 overlaps RSELx = 15. With device-to-device differences, it makes sense that some may be RSELx = 14 and others RSELx = 15. What you're observing isn't a process bug but normal operation.

    Viktorija Cecil said:

    Typical values at power up:

    RSELx = 0x0F (according to the data sheet this should always be 0x0F)

    DCOCTL = 0xAA

    Actually, the default values after a PUC are RSELx = 7 and DCOx = 3 according to the Section 5.2.5.2 in the User's Guide.

    Viktorija Cecil said:

    Value of the faulting sample:

    RSELx = 0x0E

    DCOCTL = 0xE0

    I wouldn't consider this to be a faulty sample. RSELx = 14 and DCOx = 7 is a valid configuration for 16MHz on some devices. Keep in mind that the factory-provided calibration factors were done at a supply voltage of 3V and a temperature of 30C.

    Viktorija Cecil said:

    As the controller heats up the value of DCOCTL must be increased to compensate for the clock drift due to temperature.   In the faulted unit DCOCTL was incremented until it wrapped around to 0x00 causing the clock and motor speed to drop. The lower bits of DCOCTL have no effect on the clock frequency above a value of 0xE0 so the code kept adjusting until the register wrapped around to 0.

    Simple limits have now been placed on the value of DCOCTL to prevent wrap-around. However that does not solve the adjustment problem. The faulted motor now will loose a small amount of speed as the control heats because the value of DCOCTL is at maximum.

    Solution:

    Code has been added to detect when RESEL value is 14 and when the DCOCTL value is maxed out (0xE0). If this case is persistent for 60 seconds the software writes RSEL=15 and resets DCOCTL to the mid range value. Continuous calibration then proceeds as normal.

    Again, what you're describing is completely normal and your solution follows what should be done based on operation described in the datasheet and User's Guide. As you've observed, you need to adjust the frequency across temperature to keep it close to 16MHz. You're doing that correctly.

    When DCOx = 7, the MODx bits have no effect because the DCO is already at the highest setting for the selected RSELx range. This means you'll need to manually increase RSELx by 1, as you've done. Perhaps other MSP430s support increasing RSELx automatically when DCOx = 7, but the value-line G2xx family does not.

    I hope this helps. If you have any questions, let me know.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to Viktorija Cecil
    TI__Mastermind 49692 points

    Hello Viktorija,

    Now, let me go back and discuss the BCL12 errata. The customer may not have observed the issue explained in the errata's Description, but it's something to be aware of.

    According to the Description, when switching RSELx bits from a value of <12 to a value of >13, then the issue where the resulting clock can stop before the new clock frequency is applied. After a PUC, the default value of RSELx = 7, and then they're loading the factory calibration factors with RSELx = 14 or RSELx = 15, so the clock could stop. Now, obviously when they're calibrating on the fly later, they're probably not changing RSELx from 14 or 15 to a value <12, so that's fine.

    For the workaround, there's two pieces that the customer should be aware of.

    1) Before they load the 16MHz calibration factors, they should first set RSELx to its default value of 7 BEFORE switching to the 16MHz frequency using RSELx = 14 or 15.

    2) Also, when RSELx = 15, it's recommended that RSELx gets set to the default value of 7 BEFORE accessing the DCOCTL register to modify the DCOx and MODx bits. Then, after they've finished modifying the DCOCTL register, change RSELx back to 14 or 15 in an additional step.

    Regards,

    James

    MSP Customer Applications

  • 0 in reply to James Evans
    Genius 4350 points

    James, this isn't my thread, but I believe I have a relevant question.  I use firmware that develops the missing 8, 12, and 16 MHz calibration entries for parts like the G2231 that only have the 1 MHz factory calibration, and does so without a crystal.  Basically, it just counts up the VLO for a while at the calibrated 1 MHz clock, then switches to a guess at the 8 MHz settings (range 13), sets the divider to 8, and sees if it gets the same count.  If not, it adjusts DCOCTL in the appropriate direction until the count is the same, or crosses over.  Similar adjustments to the clock, the divisors, and the count, produce 12 MHz and 16 MHz.  Of course this isn't super accurate, but as long as the VLO is stable, it works pretty well, and is arguably as accurate as the 1 MHz calibration was.  Takes less than one second.

    My question is about the DCOCTL adjustments needed while in range 15 for 16 MHz.  If I understand your post correctly, I shouldn't change DCOCTL at all while in range 15.  Is that right?  You have to go to 7 first, make the change, then go back to 15.  My routine completely violates that rule, but it seems to work fine.  The individual changes to DCOCTL are small, and increasing, so maybe that's why it works, but I've tried the firmware on a number of G2231's and it produces  consistent results on repeated runs so long as I leave a little time to cool off between runs.  I've never encounted a DCO stop so far as I know.

    Am I misinterpreting what you've said, or am I really violating the workaround?  It looks like I am.  If so, why does it still work?

    As far as changes to the range, I first set it to the calibrated 1 MHz value, which so far is always range 6, not 7, then go directly to 13, then 14, then 15, and then I step back down to 14, then 13, which is where I leave it for the rest of the program.  I think that complies with the workaround.

    It sounds like Viktorija has developed a workaround that works for the range-14 16 MHz parts.  But an alternative would be to develop range-15 values that give the same clock as the range-14 calibrated values produce, using something like my method, and replace the existing values with the new ones.

  • 0 in reply to George Hug
    TI__Mastermind 49692 points

    George Hug said:

    My question is about the DCOCTL adjustments needed while in range 15 for 16 MHz.  If I understand your post correctly, I shouldn't change DCOCTL at all while in range 15.  Is that right?  You have to go to 7 first, make the change, then go back to 15.  My routine completely violates that rule, but it seems to work fine.  The individual changes to DCOCTL are small, and increasing, so maybe that's why it works, but I've tried the firmware on a number of G2231's and it produces  consistent results on repeated runs so long as I leave a little time to cool off between runs.  I've never encounted a DCO stop so far as I know.

    Am I misinterpreting what you've said, or am I really violating the workaround?  It looks like I am.  If so, why does it still work?

    That's correct. Perhaps you're right that the incremental changes to DCOCTL prevent the errata from occurring, but overall, some users may not do these incremental changes, which could be why we recommend setting RSELx to the default value before accessing DCOCTL. Either way, I would recommend the workaround to be completely safe. Perhaps in your case, the DCO has some dead time but doesn't completely stop. Also, the errata may only happen to a handful devices out of many.

    George Hug said:
    As far as changes to the range, I first set it to the calibrated 1 MHz value, which so far is always range 6, not 7, then go directly to 13, then 14, then 15, and then I step back down to 14, then 13, which is where I leave it for the rest of the program.  I think that complies with the workaround.

    Yes, that seems to comply with the workaround.

  • 0 in reply to James Evans
    Genius 4350 points

    Thanks very much, James.  I'll change my code to comply with the workaround.

**Attention** This is a public forum