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.

MSP432P401R: External DCO Resistor behaviour

Part Number: MSP432P401R

We recently found an interesting way to brick our MSP432P401RIZXH (80 pin BGA) prototype.

We are using an external DCO resistor.  The prototypes have been working quite well for a number of months, we have 3 of them built.  Recently, however they stopped working.  We were working with a prototype that had been working and it bricked.   We couldn't figure out what we did.  And proceeded to brick the other two trying to figure out what we were doing that was bricking the chips.

Turns out that was happening is the following:

We get the POR and start executing the Reset code in the startup code. 

We initialize various parts of the system and then initialize the DCO. 

We set the CS->CTL0 register to include DCORES to enable the external resistor

At this point, when we are single stepping we lose contact via the debug probe.

What is happening is the chip is detecting a DCORES short and doing a POR, which takes us back to reset where we then do the above steps, and reset again again and again.

Now here is what is weird.  I haven't changed any of the code.  I've enabled the DCORES since inception.  The prototypes worked for quite a while (months).  And then stopped working.  The boards were supposed to have a 91Kohm resistor attached to the DCORES pin but were misloaded with 10Kohm.

  • why would the chips work correctly for some period of time.
  • what can explain the change later so the chip would now see this 10K resistor as a short?

Any clues?

  • Eric,
    I will reach out to the systems team to see if I can get some more insight into the resistor. Are you able to determine if the device is functional or stops bricking if the 10K is replaced with the 91K?

    Also, in your order of operation, it appears that you are configuring the DCO and then enabling the external resistor. The TRM states the following:
    "Switching to the external resistor mode of operation must always be done at the default DCORSEL setting (DCORSEL = 1). Failure to do so can
    result in nondeterministic behavior of the device."

    www.ti.com/.../slau356f.pdf

    Thanks and Regards,
    Chris
  • Chris Sterzik said:
    Eric,
    I will reach out to the systems team to see if I can get some more insight into the resistor. Are you able to determine if the device is functional or stops bricking if the 10K is replaced with the 91K?

    Also, in your order of operation, it appears that you are configuring the DCO and then enabling the external resistor. The TRM states the following:
    "Switching to the external resistor mode of operation must always be done at the default DCORSEL setting (DCORSEL = 1). Failure to do so can
    result in nondeterministic behavior of the device."

    www.ti.com/.../slau356f.pdf

    Thanks and Regards,
    Chris

    not sure where you are seeing my order of operation wrt the DCO configuration...   but here is how I actually do it..

    CS->KEY = CS_KEY_VAL;
    CS->CTL0 = CLK_DCORSEL | CS_CTL0_DCORES | CLK_DCOTUNE;

    I'm writing CS->CTL0 with 0x430093

    after reset CTL0 is 00010000

    so can I switch to RSEL 3 at the same time as I enable the DCORES?

    or should I first turn on the resistor and then kick the clocks up.  How long do I have to

    wait after turning on the resistor?

  • The TRM does not provide specific clarity on the timing other than the DCORES should only be set when DCORSEL = 1. I have filed a bug to ask for more specificity.

    If you could turn on the resistor first and then increase the clock, then I think you could at least eliminate that as a possible issue.

**Attention** This is a public forum