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

MSP430FR4133: What is the fastest way to guarantee FRAM has been accessed?

adevries
Intellectual 945 points
Part Number: MSP430FR4133


Hello TI Forum,

I was reading the erratasheet for the MSP430FR4133, and I came across errata number GC5. One of the suggested workarounds says:

After LPM wake up, clear GCCTL1.UBDIFG and GCCTL1.CBDIFG, and then reinitialize the GCCTL0 register after the first valid FRAM access has been completed. For the valid FRAM access the user has to  consider possible cache hits which depends on implementation.

I was planning to implement this workaround, but I'm confused on how to guarantee I will access the FRAM and not the cache. Since the cache is 16 bytes, can I guarantee FRAM access if I read 17 bytes? Is this the fastest/most efficient way to achieve this goal?

Also, how does the microcontroller determine what information to store in the cache? Lastly, if the cache loads new data from FRAM, does that count as a "valid FRAM access" per the workaround? Or is it only a valid FRAM access if the microcontroller core does the accessing?

Thanks!

  • 0
    Guru 24805 points

    Your code resides in FRAM so that is likely to do the job all on its own. Since the locations in your ISR are going to be ejected from the cache by non-ISR code running, you get that FRAM access automatically.

  • 0 in reply to David Schultz
    Intellectual 945 points

    Hi David,

    Thanks the reply! I haven't really dealt with a cache system before, so this is still a little confusing for me. How do you know that the cache will be full of ISR locations once the MCU wakes up from an interrupt? I can't find any place that talks about how the cache decides what to store, so what makes you think that?

    Secondly, the wording of the workaround suggests that I don't want to reinitialize the GCCTL0 register immediately after waking up, because the FRAM may not have been accessed yet. I'm sure that once a couple dozens line of code have run, I can safely assume the FRAM has been accessed by then, but is there any more precise of a way to determine when the access happens?

  • +1 in reply to adevries
    Guru 24805 points

    The cache speeds up FRAM access by reading 4 words on a cache miss. In sequential code this means that 3 of 4 reads will be from cache. It varies (or at least the description in the documentation does) between devices but it appears this device has four 64 bit cache lines. A cache miss will result in an FRAM read of 64 bits which replaces the contents of one of those lines.

    Normal code execution will load the cache from locations other than within your ISR. So when the interrupt is serviced, except in unusual cases, the first fetch of code in the ISR will cause a cache miss and FRAM read. The unusual cases being where very little code outside of the ISR was executed since the last time the ISR ran. And a really small ISR.

  • 0 in reply to David Schultz
    Intellectual 945 points

    Hi David,

    Thanks for briefly explaining the cache, that makes a lot of sense! It sounds like as long as enough code is run between ISRs, I can pretty safely assume servicing the ISR will cause a valid FRAM access, after which I can safely reinitialize the GCCTL0 register.

    Thanks for the help!

**Attention** This is a public forum