• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 1540 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.

CCS/MSP430FR5989: MSP430 resets continuously with fast clock depending on order of clock initialization

Russell Merrick
Intellectual 260 points
Part Number: MSP430FR5989
Other Parts Discussed in Thread: MSP430FR6989

Tool/software: Code Composer Studio

I have the following code:

    // Setup to use internal DCO at 16 MHz
    CS_setDCOFreq(CS_DCORSEL_1, CS_DCOFSEL_4);
    //Set ACLK=DCO
    CS_initClockSignal(CS_ACLK,CS_VLOCLK_SELECT,CS_CLOCK_DIVIDER_1);
    //Set SMCLK = DCO with frequency divider of 1 for peripherals
    //(16 MHz is a good rate for UART baud rate generation)
    CS_initClockSignal(CS_SMCLK,CS_DCOCLK_SELECT,CS_CLOCK_DIVIDER_1);
    //Set MCLK = DCO with frequency divider of 1 for main CPU
    CS_initClockSignal(CS_MCLK,CS_DCOCLK_SELECT,CS_CLOCK_DIVIDER_1);

When I run these lines, the system resets continuously and I see the HFXTOFFG bit is set.  However if I make this change:

    // Setup to use internal DCO at 16 MHz
    CS_setDCOFreq(CS_DCORSEL_1, CS_DCOFSEL_4);
    //Set ACLK=DCO
    CS_initClockSignal(CS_ACLK,CS_VLOCLK_SELECT,CS_CLOCK_DIVIDER_1);
    //Set MCLK = DCO with frequency divider of 1 for main CPU
    CS_initClockSignal(CS_MCLK,CS_DCOCLK_SELECT,CS_CLOCK_DIVIDER_1);
    //Set SMCLK = DCO with frequency divider of 1 for peripherals
    //(16 MHz is a good rate for UART baud rate generation)
    CS_initClockSignal(CS_SMCLK,CS_DCOCLK_SELECT,CS_CLOCK_DIVIDER_1);

Everything works fine!  Also if I configure all clocks at the same time that is fine as well.  Also if I drop to 8 MHz that's fine as well.  It's only the combination of 16 MHz and initalizing SMCLK *before* MCLK that causes the processor to continuously reset.

  • 0
    TI__Guru 60201 points

    Hi Russel,

    Can you capture the CS registers in code composer studio as shown here?

    Capture both working and non-working, if you can.

    Thanks,

  • 0 in reply to Dennis Lehman
    Intellectual 260 points

    It's a bit tricky... I'm able to capture working configuration no problem.  But when it fails these registers get reset.  Also this failure occurs sometimes.  If I step through the code it seems like it has a better chance of successfully initializing the clock system vs. just letting it free-run.  It looks to me like something is not settling correctly, maybe a counter is just on the edge or something.  Anyway here's the image for when it's working:

    And here's a failed version... I put in breakpoint just before the clock registers got initialized (in the wrong order).  This was after it recovered from a reset.

  • 0 in reply to Russell Merrick
    TI__Guru 60201 points

    Hi Russel,

    I'm not seeing why this would cause you this problem.  In fact, looking at our example code for this family of devices (see below), it sets the SMCLK first, then the MCLK.

    Do you set the FRAM wait state after clock initialization as shown below?

    This is required if operating the MCLK above 8MHz.

  • 0 in reply to Dennis Lehman
    Intellectual 260 points

    Dennis, I do set the wait states to 1, but I do it prior to the clock initialization.  I could move it to after the clock init if that's better.

  • 0 in reply to Russell Merrick
    TI__Guru 60201 points
    Hi Russell,

    No, actually, according to the device user's guide in section 7.5, it is preferred to set the wait states prior to changing the clock, especially if bumping up the frequency above 8MHz. Otherwise you run the risk of generating PUC reset and erratic FRAM access. I'll have to speak with our team that created this example code.

    Let's go back and focus on your clocking system. It appears from your "working" register contents you are enabling the HFXT oscillator with a HFXT selection of 16 to 24MHz crystal? Is this correct?
  • 0 in reply to Dennis Lehman
    Intellectual 260 points

    I'm currently enabling the HFXT input in Bypass mode.  I'm using an external 16 MHz single-ended clock as an input to the HFXIN pin.  

    I've tried exactly the same code using the DCO (16 MHz) instead of the external clock and I have the same problem.  Initializing the SMCLK prior to MCLK causes system to reset sometimes.  

  • 0 in reply to Russell Merrick
    TI__Guru 60201 points
    Hi Russell,

    Since I have not been able to reproduce this issue using a MSP430FR6989 launch pad (same device family as FR5989) and same code you are using, I'm a little stumped. Do you only have one FR5989 that demonstrates this issue or multiple ones?

    Also, what voltage are you operating at?
  • 0 in reply to Dennis Lehman
    Intellectual 260 points
    I see this on the 3 PCBs that we have spun. We are operating at 3.3V. Thanks for your help on this one. For now the workaround is "configure all clock registers at the same time."
  • 0 in reply to Russell Merrick
    TI__Guru 60201 points

    Hi Russell,

    I'm still trying to reproduce this issue on my end and did notice an errata CS12 on this device that may offer a clue.  In your code  you are setting the DCO to 16MHz before initializing the individual clock sources and divisors.  Have you tried setting the DCO to 16MHz afterwards?

  • 0 in reply to Dennis Lehman
    TI__Guru 60201 points
    Hi Russell,

    Since your workaround appears to be working for you I will close this thread for now. When I get a resolution to this issue I will post our findings.

**Attention** This is a public forum