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

MSP430F67471A: Are there any problems switching MCLK's source before entering and exiting LPM?

Keirs
Expert 2605 points
Part Number: MSP430F67471A

Hello.

I have a question.

Are there any problems implementing following process codes?

1.Before entering LPM3, switch MCLK's source from 8MHz DCO to 32kHz Crystal Oscillator.

2.Enter LPM3.

3.After interrupting by external trigger, execute code with MCLK's source set to 32 kHz Crystal Oscillator.

4.If it is necessary to operate at high speed, switch MCLK's source from  32kHz Crystal Oscillator to 8MHz DCO.

 Could you give me any advice?

Regards,

uchida-k

  • 0
    TI__Guru**** 202106 points
    Hello uchida-k,

    I do not know of any problems with implementing the code described, as mentioned in Section 5.2.13 of the User's Guide the clock system synchronizes the source switching to avoid race conditions. You should only have to modify the UCSCTL4 SELM bits after clock initialization and implement a fault flag clearing loop, please pay attention to the UCS11 errata description and workaround.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 2605 points
    Hi Ryan,

    Thank you for your reply.
    You say that I should only have to modify the UCSCTL4 SELM bits after clock initialization and implement a fault flag clearing loop,
    but UCS11 errata workaround say that I should clear all the fault flags in UCSCTL7 register once after changing any of the
    SELM/SELS/SELA bits in the UCSCTL4 register.

    Is it enough to modify UCSCTL4 SELM bits after clock initialization and implement a fault flag clearing loop wihout clearing all the fault flags in UCSCTL7 register?

    Could you give me something advices?
    Regards,

    uchida-k
  • 0 in reply to Keirs
    TI__Guru**** 202106 points
    Hi uchida-k,

    Simply modify UCSCTL4 and perform the UCTCTL7 fault flag clear loop, this will clear any erroneously-set fault flags from the UCS11 errata. This follows standard operation but I wanted to make sure that you were aware of the errata.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    Expert 2605 points

    Hi Ryan

    Could I ask you one more question?

    I connected XT1 to Crystal Oscillator 32.768kHz.
    And I am using DCO with FLL referenced XT1 and setting 8MHz.

    Which of the following use case is low power consumption?

    1.
    　a.Before entering LPM3, switch MCLK's source from 8MHz DCO to 32.768kHz XT1 Oscillator.

    　b.Enter LPM3.

    　c.After interrupting by external trigger, execute code with MCLK's source set to 32.768 kHz Crystal Oscillator.

    　d.If it is necessary to operate at high speed, switch MCLK's source from 32.768kHz Crystal Oscillator to 8MHz DCO.

    2.
    　a. MCLK is sourced from 8MHz DCO.

        b.Enter LPM3.

        c.After interrupting by external trigger, execute code with DCO remaining at 8MHz.


    Could you give me something advices?


    Regards,

    uchida-k

  • 0 in reply to Keirs
    TI__Guru**** 202106 points
    Hey uchida-k,

    This depends on how long your ISR is and what it accomplishes, whether you exit the ISR into active mode or go back to LPM3, and how long overall your application stays in active mode. The DCO is disabled in LPM3 so long as it doesn't source ACLK and therefore does not draw any power while the MCU is asleep. Likewise the DCO can remain disabled in active mode if it does not source MCLK/SMCLK but this mode will nevertheless draw more current than LPM3, you need to figure out if it is more beneficial to service your ISR at 32 kHz or 8 MHz. You may need to generate some test code to come to a proper conclusion.

    Regards,
    Ryan

**Attention** This is a public forum