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.

Still having problems despite the new BCL12 workaround

Other Parts Discussed in Thread: MSP430G2452, MSP430G2553, MSP430G2001

Hi,

For the past couple of days I've been investigating a hang that I've been getting on an msp430g2452 fitted to a launchpad. I narrowed down the issue to some code that was attempting to change the DCO frequency. This was surprising as I'd been careful to apply the workarounds mentioned in the BCL12 erratum (as of October 2012). Also, I was sourcing MCLK from DCO/8 so as not to exceed 16MHz. Despite this my program was freezing up, and I was getting the following message in the debugger output:

MSP430: Can't Single Step Target Program: Error during step; unknown state
MSP430: Trouble Halting Target CPU: Could not terminate EEM polling thread.

The same code worked fine on a msp430g2553 and a msp430g2001 (unfortunately I only have one 2452 chip). After boiling down the problem code to a minimal test program, I found that the 2452's DCO was locking up if I tried to set DCOCTL to a value greater than 0xCF before setting RSEL to 15 (while respecting BCL12). The VLO was still running, and I was even able clock TimerA from the VLO to flash a LED after the CPU had hung. Attempting the same with TimerA clocked by DCO produced no flashes. The WDT+ was unable to reset the chip irrespective of its clock source.

Before posting a message about this I decided to take one last look at the errata page to see if there were any updates. Sure enough, all the value line errata files were updated on 17th January. Reading BCL12, I noticed this addition:

"In the majority of cases switching directly to intermediate RSEL steps as described above will prevent the occurrence of BCL12. However, a more reliable method can be implemented by changing the RSEL bits step by step in order to guarantee safe function without any dead time of the DCO."

I tried this suggestion in my test program, and while it allowed me to raise DCOCTL to 0xD7 safely I still get a hang if I go higher than that.

Is that a known issue?

Thanks, Rob

[EDIT] To clarify my question, I'd like to know whether the new BCL12 advice quoted above is expected to completely resolve the DCO lockup issue. The words "a more reliable method" imply it might only be a partial fix, while "guarantee safe function" suggests the opposite.

  • Problem is that when switching RSEL, one erroneous DCO tick may happen that is only a fraction of the normal clock cycle. This will crash the CPU.

    It's a good idea to set the MCLK divider to 4 before changing RSEL, and immediately back after. THis way, the erroneous clock tick makes only 1/4 of the resulting cycle.

    It's also recommended to reduce DCOx before increasing RSEL, unless you definitely know that the resulting frequency isn't beyond maximum speed. Also enusre that your supply voltage is high enough for the new speed.
    The datasheet maximum is only the guaranteed one. If the code worked with a different MSP, it may still be that this other MSP was still running outside specs but didn't crash.

    Also, the RSEL and DCOx settings result in different frequencies on different MSPs. Even of the same type. That's why there are calibration values in info memory.

  • Thanks for your reply, Jens-Michael.

    I think I've already covered all the potential pitfalls you've mentioned. I'm running with the MCLK divider set to 8 throughout, which should protect the CPU from any glitched DCO cycle as you described. Also it prevents the CPU from running above maximum clock speed (the DCO would need to be running at 128MHz to overclock the chip!). I've checked the datasheets and all three chips I'm using have a maximum CPU clock frequency of 16Mhz @ 3.3V. The MSP-EXP430G2 launchpad is specified as providing 3.6V to the target chip, so I should be safe on voltage too.

    I'm wondering whether it might help to leave some delay between steps when modifying RSEL "step by step" as described in the updated BCL12. At present I'm changing the value in a tight loop, so perhaps the DCO doesn't have time to settle between changes. Also I'm thinking that it could help to clock the CPU using the VLO during the DCO frequency change. If the crash is being caused by a temporary DCO glitch, then sourcing MCLK from VLO might isolate the processor from the glitch and allow safe operation. I'll try both of these options and follow up later...

  • Robert Cowsill said:
    I'm wondering whether it might help to leave some delay between steps when modifying RSEL "step by step" as described in the updated BCL12. At present I'm changing the value in a tight loop, so perhaps the DCO doesn't have time to settle between changes. Also I'm thinking that it could help to clock the CPU using the VLO during the DCO frequency change. If the crash is being caused by a temporary DCO glitch, then sourcing MCLK from VLO might isolate the processor from the glitch and allow safe operation. I'll try both of these options and follow up later...

    Unfortunately neither of these ideas helped. The extra delays had no effect. Running the CPU on VLO let execution continue after setting the DCO, but attempting to switch the CPU back onto DCO caused the hang again.

  • So what are your exact settings? Not only DCOx, but the whole bunch.

    Note that the same settings may have significantly different results on different MSP models, beyond the differences between individual MSPs of the same model.

  • I was preparing a minimal code example to demonstrate what causes the issue on my "problem chip" when I found a setup sequence that succeeded!

    The test program's clock setup was DIVM=3 (divide by 8), RSEL=15, DCO=6, MOD=16. According to the MSP430x2xx Family User's Guide and the datasheets for msp430g2553, msp430g2452 and msp430g2001, that produces a DCO frequency of 12 to 26MHz. Notice that I have the MCLK divider set to 8 so the maximum clock speed (16MHz for all three chips) is not exceeded. Also notice that under these conditions there is a conflict between the standard clock initialisation advice and the final section of BCL12. Standard advice is to clear DCOCTL, set BCSCTL1 and then set DCOCTL (Page 280 of SLAU144I). BCL12, however, has this to say:

    "In case RSEL is at 15 (highest setting) it's recommended to set RSEL to its default value first (RSEL = 7) before accessing DCOCTL to modify the DCOx and MODx bits. After the DCOCTL register modification the RSEL bits can be manipulated in an additional step."

    In other words, if I follow the standard advice I'd be setting DCOCTL when RSEL is already 15, potentially triggering the BCL12 bug. If instead I set DCOCTL first (while RSEL is at its power-on default of 7) then I'm not using the sequence specified in the user guide. There's no way I can do both.

    My interpretation of the sequence in the user guide is that it's designed to avoid overclocking the CPU. Say you're changing from high RSEL/low DCO to low RSEL/high DCO, or vice-versa. This sequence guarantees that you never end up temporarily running high RSEL/high DCO, clocking the CPU at ~26MHz and causing a hang. In my case that's not a concern since I'm dividing the DCO frequency by 8 to source MCLK.

    For that reason I originally decided to follow the BCL12 advice. When I was preparing the test code, I quickly tried swapping the lines that set BCSCTL1 and DCOCTL, meaning the code ignored the BCL12 recommendation and followed the user guide instead. That fixed the issue, and I was then able to modify the code to set the DCO all the way up to RSEL=15, DCO=7, MOD=0!

    I'm not entirely comfortable with ignoring part of the BCL12 erratum, but if doing so works who am I to argue? :)

  • Robert Cowsill said:
    I'm not entirely comfortable with ignoring part of the BCL12 erratum, but if doing so works who am I to argue?

    I understand your worries. I wouldn't be comfortable with this too, but as you say, if it works that way, then it works that way. Especially if it doesn't work the other way...
    I just would prefer to know why it is working that way only. ;)

  • Hi Robert,

    BCL12 can be very confusing with all the different cases but from what I understand, you are following this procedure during clock initialization, is that correct? In such case, you can just follow the default 3-step sequence from the User's Guide: 1)clear DCOCTL, 2)write BCSCTL1, 3)write DCOCTL

    This is from the errata doc:

    Note that the 3-step clock startup sequence consisting of clearing DCOCTL, loading the
    BCSCTL1 target value, and finally loading the DCOCTL target value as suggested in the
    in the "TLV Structure" chapter of the MSP430x2xx Family User's Guide is not affected by
    BCL12 if (and only if) it is executed after a device reset (PUC) prior to any other
    modifications being made to BCSCTL1 since in this case RSEL still is at its default value
    of 7. However any further changes to the DCOx and MODx bits will require the
    consideration of the workaround outlined above.

    The cases described in the errata apply when the DCO is modified after startup (i.e. periodic calibration). I.e. if the calibration procedure changes RSEL to 15 and uses DCO+mod for finer steps, the usual procedure would be to increment  DCOCTL directly, but the errata says that RSEL should be changed to 7, then DCOCTL is incremented and then RSEL is changed to 13 (due to another case) and then to 15. An even better recommendation would  be to change RSEL from 15 to 7 step by step, increment DCOCTL and then increment RSEL from 7 to 15 step by step.

    All these cases make the implementation odd, but as mentioned, the important thing is that the basic initialization which is the most common case shouldn't be affected by BCL12.


    Regards,

    Luis R



  • Hi Luis,

    I was working on a calibration program that needed to change the DCO setting repeatedly at runtime, hence the need to pay attention to BCL12.

    What I found was that the BCL12 advice detailed above did not prevent DCO lock-up on a specific msp430g2452 chip I was testing on. Any attempt to set RSEL to 15 while DCO+mod were non-zero caused the DCO to hang, irrespective of the previous value of RSEL.

    Through experimentation I found a DCO configuration sequence that worked reliably. It starts by running a loop that decrements DCO+mod step-by-step until they reach zero, then increments RSEL to the target value step-by-step and finally increments DCO+mod step-by-step to the target value.

    Thanks, Rob

**Attention** This is a public forum