• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 80 subscribers
  • Views 344 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.

MSP430FR5869

Victor Zheng
Intellectual 1550 points

Other Parts Discussed in Thread: MSP430FR5869

Team,

I used the MSP430FR5869. I find ACCTEIFG was set in my code. I have checked the system clock, it did not exceed 8 MHz. I want to know

  • there is any other condition can triger this bit besides the FRAM access time is violated
  • How the CPU know if the real access time have exceed 8M? it monitor the configuration or monitor real clock?

Thank you

Victor

  • 0
    TI__Guru**** 220387 points
    Hi Victor,

    Do you ever modify the value of FRCTL0 inside of your firmware? What are you attempting to set your system frequency to? Is the ACCTEIFG set if NWAITSx = 1? Does this behavior exist outside of the debugger? Can it be easily cleared by writing a 0 to it or will it be re-asserted immediately afterward? This flag should only be set from the combination of a wrong NWAITS setting and violation of FRAM access. The ACCTEIFG bit does not trigger a PUC or change the SYSRSTIV register value. The device generates wait states to make sure that the system clock for the CPU does not exceed the FRAM access and cycle time requirements.

    Regards,
    Ryan
  • 0 in reply to Ryan Brown1
    TI__Genius 14165 points
    Hi Victor,

    please also consider ERRATA CS12 for possible DCO overshoots. See link below:

    www.ti.com/.../slaz473

    Best regards,
    Dietmar

**Attention** This is a public forum