• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 80 subscribers
  • Views 377 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.

MSP430FR5994: LOCKLPM5 vs LFXT

Fred P
Expert 2235 points

Part Number: MSP430FR5994
Other Parts Discussed in Thread: ENERGYTRACE

Tool/software:

It appears that LOCKLPM5 bit does NOT apply to PJSEL0.4 (and PJSEL.5, maybe).

I can't find any statement about that in the documentation (UG revP April 2020). 

What I find, which is not ambiguous at all is:

12.3.1 Configuration After Reset
After a BOR reset, all port pins are high-impedance with Schmitt triggers and their module functions
disabled to prevent any cross currents.

However, my investigation shows otherwise.

Upon reset, BEFORE clearing LOCKLPM5 bit, my code starts the LFXT:  it sets PJSEL bits, clears fault flag and asserts the flag is well cleared.  Tracing all of this in the debugger confirms it all works.

It should not because LOCKLPM5 is STILL set.  Pins functions should not be applied until it is cleared.  Right?

Not clearing LOCKLPM5 bit is my mistake and I am very much puzzled that LFXT runs fine.  Remaining of my application relies on a proper 32.768kHz clock and it behaves ok.  LFXT really is running ok!

To double check the behavior, I commented out PJSEL configuration.  LFXT does not start.  LFXT fault flag is set again automatically upon clearing, just as it should. 

So it appears changes to PJSEL.4 and PJSEL.5 DO apply even while LOCKLPM5 bit is set.

What do you think?

Regards,

  • 0
    Guru 26365 points

    I tested with this bit of code on the FR5969 (also a slau367 guide part) Launchpad:

      PJSEL0 |= BIT4|BIT5;        // enable LFXT pins.
  //  PM5CTL0 &= ~LOCKLPM5;
  CSCTL0 = CSKEY;
  CSCTL2 = SELA__LFXTCLK|SELS__DCOCLK|SELM__DCOCLK;
  CSCTL3 = DIVA__1|DIVM__1|DIVS__8;
  
  CSCTL4 &= ~LFXTOFF;         // LFXT on
  // wait for it to start
  do {
    CSCTL5 &= ~LFXTOFFG;      // clear osc fault flag
    SFRIFG1 &= ~OFIFG;
  } while(SFRIFG1 & OFIFG);
  

  TA0CCR0 = 32768/64;
  TA0CCTL0 = CCIE;
  TA0CTL = TASSEL__ACLK|MC__UP|TACLR;
  
  __bis_SR_register(GIE);       //  interrupt

  while (1);

    With or without clearing LOCKLPM5, it falls through to the while(1) loop. As a test, removing the PJSEL0 line results in it getting stuck in the OFIFG loop.

    So this does seem to be a thing. Not a bug but just something unexpected. Handy if you configure clocks before clearing LOCKLPM5 without thinking.

  • 0 in reply to David Schultz
    TI__Genius 13605 points

    Thank you David for comment.

    Hi Fred, does LOCKLPM5 bit works for other IO pins, or you just observed that it does not work for PJSEL0.4 in your test?

  • 0 in reply to Pengfei Xie
    Expert 2235 points

    Hi Pengfei,

    I'm pretty sure LOCKLPM5 works for other I/Os or I would have some glitches here and there after a reset.  Everything looks ok.  Besides, that would be unlikely for such a bug to go unnoticed for so long.

    But LFXT behabior vs LOCKLPM5 bit may be troublesome...   Out of LPM3.5 since PJSEL bits are reset and LOCKLPM5 does not apply, it implies that LFXT stops and has to be restarted.  This glitch in LFXT activity will impact on timekeeping by the RTC.

    To which extend? I don't know. MODOSC should take over while LFXT is out but its tolerance margin is huge.

    In any case, I feel it is relevant that all of this be mentioned in the documentation (UG or errata, up to you).

    Don't you think?

  • 0 in reply to David Schultz
    Expert 2235 points

    Not that handy since it means LFXT stops out of LPM3.5 ...

  • 0 in reply to Fred P
    TI__Genius 13605 points

    Hi Fred,

    Sorry for the inconvenience. 

    What if you configure LFXT immediately after MCU reset? I'm not sure whether it could work as an workaround to minimize the impact of this issue. 

  • 0 in reply to Pengfei Xie
    Expert 2235 points

    That's what I've been doing since day 1, only to realize recently (when setting up LPM3.5 wakeup), that something was wrong in my code but  working nonetheless.  

    LFXT/MODOSC backup mecanism kept things working for us so it went unoticed.

    The timekeeping precision had not been measured yet.

    According to EnergyTrace, MODOSC is off in LPM3.5.  Therefore, LFXT glitches only at wakeup.

    Hopefully,  it won't impact much timeskeeping as  wakeup from LPM3.5 should not happen that often.

    But some applications other than ours might suffer much more from that behavior. 

    Please update documentation accordingly.

    Regards,

**Attention** This is a public forum