• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 545 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.

MSP430F5438A: Meaning of FLASH34 errata

Piergiuseppe Tundo
Genius 3155 points
Part Number: MSP430F5438A

Hello.

I cannot fully understand following errata from SLAZ290T:

FLASH34: FLASH Module
Function: Concurrent flash read during bank erase fails
Description: Code residing in flash cannot be executed during a bank erase.
Workaround: Place the code to be executed during bank erase in RAM.

At section 7.3.1.4 (Initiating Erase From Flash), Family User's Guide (SLAU208Q) asserts:

(...) For any segment erase, the CPU is held until the erase cycle completes regardless of the bank the code
resides in. After the segment erase cycle ends, the CPU resumes code execution with the instruction
following the dummy write.

Hence the errata is saying that CPU isn't held as expected and flash erase must always be initiated from RAM?

What is the result of failed concurrent read? I'm occasionally experimenting a flash password violation PUC when my (bank) erase function is initiated from (another bank of) flash. Is this a known behavior?

Thank you in advance.

Best regards,

Peppe

  • 0
    Guru 26200 points
    Hello Piergiuseppe,

    the errata is more relevant than the user's guide so you should read both documents in reverse order than you have presented.

    Function: Concurrent flash read during bank erase fails
    Q: Hence the errata is saying that CPU isn't held as expected and flash erase must always be initiated from RAM?
    A: Yes. You cannot safely jump to RAM after FRAM erase has been initiated.

    Q: What is the result of failed concurrent read? I'm occasionally experimenting a flash password violation PUC when my (bank) erase function is initiated from (another bank of) flash. Is this a known behavior?
    A: Description: Code residing in flash cannot be executed during a bank erase. Function: Concurrent flash read during bank erase fails.
    Errata says that during a bank erase you cannot reliably read from any FRAM bank.

    Q: Is this a known behavior?
    A: The above answer says, YES.
  • 0 in reply to Tomasz Kocon
    Genius 3155 points
    Dear Tomasz, thank you for your prompt reply.

    Sure, I know about errata greater relevance over user's guide.

    But after having read your reply I still think that the description of that errata is really misleading.
    It states that it is not possible to fetch any code from the flash while it is being erased, contradicting the fact that the CPU should be held waiting for completion.

    Then it should instead clarify that, contrary to what is expected, the CPU isn't held at all, hence it keeps fetching code from the flash, and this operation fails. However, it is not absolutely clear how it fails: e.g., in all other cases where a fetch isn't possible, the CPU reads 0x3FFF, which is equivalent to a jump to the same PC, and this keeps the CPU locked exactly as it should by design.

    Finally I point out that I'm talking about flash and not FRAM, but maybe yours was just a typo.
  • 0 in reply to Piergiuseppe Tundo
    Guru 26200 points
    Dear Piergiuseppe,

    <<< Sure, I know about errata greater relevance over user's guide.
    >>> Great! I prefer to read errata without a context of a user guide to avoid any expectations and assumptions, to find the worst case.

    <<< It states that it is not possible to fetch any code from the flash while it is being erased.
    >>> I do not agree with you. It says that the reading from any flash location fails.

    <<< However, it is not absolutely clear how it fails
    >>> I agree with you. My legal counsel used to say: It is not signed until it is signed. If it fails, it fails.

    <<< in all other cases where a fetch isn't possible, the CPU reads 0x3FFF, which is equivalent to a jump to the same PC, and this keeps the CPU locked exactly as it should by design.
    >>> Great that you know such a detail and a concept!

    <<< Finally I point out that I'm talking about flash and not FRAM, but maybe yours was just a typo.
    >>> Not a typo. 2-3 phone calls when answering to you and FRAM, SRAM, Flash, etc. makes no difference.

    Do you have a concept how to avoid "occasionally experimenting a flash password violation PUC"?
  • 0 in reply to Tomasz Kocon
    TI__Genius 14165 points
    Tom,

    please note that the ERRATA FLASH 34 is talking about the BANK erase feature of the flash.

    While the abstract of the user guide you mention talks about SEGMENT erase. This is a big difference which will be set up with the MERAS and ERASE bits inside the FCTL1 register.

    To clarify
    1. the user guide says in chapter 7.3.1.4 that during BANK erase code execution is allowed from FLASH and RAM.
    2. However the FLASH34 ERRATA says that execution from FLASH for BANK erase does not work
    -> Means only execution from RAM is possible during BANK ERASE and therefore the BANK erase should be done from RAM!

    3. User guide states also that for Segment ERASE the CPU is held at all and no code execution is possible during segment erase

    Hope this helps to better understand the user's guide and the ERRATA in combination. The effect is that reading during bank erase will not work reliable.
    To better understand how you get the PUC triggered by flash password violation I need the sequence of code.
    But if you initiate a BANK ERASE from FLASH and have code placed after this which will write the PW to FCTL1 it can happen because the read of the code or data might not work reliable.
    Therefore please put BANK erase code to RAM.
  • 0 in reply to Dietmar Walther
    Genius 3155 points

    Dear Dietmar Walther, thank you very much for your clarifications.

    At this point I would only add that the bank erase RAM function must be in a critical section to avoid any need of fetching other code from flash (e.g. by ISRs).

    The critical section can be closed after BUSY returns 0, and, to be paranoid, besides GIE should also disable any previously enabled NMI.

    It's worth noting all this also implies that latest DriverLib bank erase implementation (FlashCtl_eraseBank) is faulty, as it is put in flash and doesn't prevent IRQs.

    Best regards,

    P.

  • 0 in reply to Piergiuseppe Tundo
    TI__Genius 14165 points

    Piergiuseppe,

    you are absolutly correct clearing GIE to prevent flash access is necesary besides checking the BUSY in RAM until bank erase is done.

    Thanks for the information with respect to the DriverLib I will take care to get this addressed.

    Best regards,
    Dietmar

**Attention** This is a public forum