• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 622 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.

Original question:

CCS/MSP430FR6989: How to return from NMI subroutine function back to main program.

CCS/MSP430FR6989: Code review on MSP430 UNMI handler and clock initialization

KL74
Prodigy 90 points

Part Number: MSP430FR6989

Tool/software: Code Composer Studio

This post is related to the response by  in this reply: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/673619/2479155?tisearch=e2e-sitesearch&keymatch=UNMI#2479155

In the code, found in the file msp430fr69xx_of_lfxt1_nmi.c, it allows writing to the CS registers by performing 

CSCTL0_H = CSKEY >> 8;

But no where after the fact is the passcode written again to lock the CS registers.  Does this mean that the CS registers are not locked again, allowing all future writes to CS to be performed?  If so, I would suspect that this isn't best practice?

Also, inside of the UNMI ISR there is a:

__delay_cycles(60000);                  // Time for flag to set

Is it documented anywhere on what the proper delay time is, or why it should be done?  Is it being done just so that the user can see the LED blink, or does it take a certain amount of cycles to clear the flag?  If so, what is the consequences if you remove the delay, if any?

After UNMI ISR is service (has completed running), does the micro continuing running where it left off before the fault?

Lastly, regarding the UNMI ISR again, if the code was changed to:

  do
  {
    CSCTL0_H = CSKEY_H;                     // Added --- Unlock CS registers
    CSCTL5 &= ~LFXTOFFG;                    // Clear XT1 fault flag
    SFRIFG1 &= ~OFIFG;
    __delay_cycles(60000);                  // Time for flag to set
    P1OUT ^= BIT0;                          // Toggle P1.0 using exclusive-OR
    CSCTL0_H = 0;                           // Added --- Lock CS registers
  } while (SFRIFG1 & OFIFG);                // Test oscillator fault flag

Would unlocking and locking the CS registers in this fashion cause any issues?  

  • 0
    TI__Mastermind 24275 points

    Hi KL74, Thanks for your comment!

    Q: Does this mean that the CS registers are not locked again,

    A: CS registers are not locked again until device power up agian, this is the description of CSKEY in slau367o: CSKEY password. Must always be written with A5h; a PUC is generated if any other value is written. Always reads as 96h. After the correct password is written, all CS registers are available for writing.

    Q: Is it documented anywhere on what the proper delay time is, or why it should be done?  Is it being done just so that the user can see the LED blink, or does it take a certain amount of cycles to clear the flag?

    A: I think it is just for demo. if the delay counter is reduced, more times do while cycle will be performed

    Q: Lastly, regarding the UNMI ISR again, if the code was changed to:

    A: if CSCTL0_H is clear in the do while cycle, a PUC is generated if any other value is written. In this case, the do while cycle can't be performed. I don't think this is the correct clear and polling checking method.

  • 0 in reply to Xiaodong LI
    Prodigy 90 points

    Thanks for you reply  

    What are the implications of a PUC being generated.  Does a full reset occur?  Something else?  As I type this I'm also reading into it.

    The code I'm working with writes 0 after writing the CS registers and the firmware seems to run normally.  This code has been in place and in the field for awhile now.  If we wrote CSKEY to 0 in a loop, then it would generate the PUC constantly and wouldn't that prevent firmware from running, yet we see the application run?

    See CS12 in slaz473ad, part of the workaround is to write a non-0xA5 value to CSCTL0 to lock the registers again.

  • 0 in reply to KL74
    TI__Mastermind 24275 points

    Hi KL74, Thanks for your comment!

    I check again MSP430FR6989 UG 1.2, you are correct! PUC will not cause RESET (BOR or POR). as my understanding, PUC will clear some register (-0,-1 Condition after PUC). Hence, wroten CSKEY to 0 is the good practice to lock CS registers as the description in CS12 in slaz473ad.

**Attention** This is a public forum