MSP430FR5989: UBDIFG and UBDRSTEN; GC5 Errata

Hi Santosh,

I am looking into this and will provide an update tomorrow.

Thanks,

Mitch

Hi Santosh,

"if I have GCCTL0.UBDIE = 0, GCCTL0.UBDRSTEN=0 and GCCTL0.CBDIE = 0,  is it possible to have UBDIFG bit set by HW while the error reporting is turned OFF and later on when SW enables the Error reporting, for ex: sets GCCCTL0.UBDRSTEN = 1, then I get a PUC immediately."

Yes, this is correct. The UBDIFG flag will get set in HW regardless of UBDIE and UBDRSTEN settings IF an uncorrectable bit error was detected in FRAM memory. However, an NMI event or a PUC reset will only occur if the UBDIE or UBDRSTEN bits are also set.

If the UBDIFG flag is set, but UBDRSTEN = 0, you will not get a PUC. When UBDRSTEN = 1 and if the UBDIFG flag was previously set, you will immediately get a PUC. 

"If so, it is safer to clear the UBDIFG before I turn ON the error reporting (PUC or NMI) right?"

It's definitely safe to do this, but if you enable UBDRSTEN in the beginning of your program, you probably do not need to. Please note that this is assuming no LPM modes have been entered and no GC5 conditions have occurred. If UBDRSTEN is enabled later in the program after many reads/writes, then yes I would recommend doing this right before setting UBDIE or UBDRSTEN since there is a chance the UBDIFG flag could be set from an actual FRAM error.

"This in relation to the GC5 Errata, does it make sense to include clear the UBDIFG flag (any other FRAM error detection flags) before re-initializing the GCCTL0 to enable PUC generation?"

Assuming that you are using LPM modes in this scenario (since that's when the GC5 errata can occur) then yes, you will want to clear the UBDIFG flag before enabling PUC generation. 

"W.r.t GC5 errata work around how is it guaranteed that the first access to FRAM after wake up doesn't set the UBDIFG?"

Looking at the way the errata is worded, I don't think it's guaranteed that the first access to FRAM after wake up won't set the UBDIFG. The errata states that the GCCTL0 register needs to be reinitialized after the first FRAM access. To be safe, you can clear UBDIFG before reinitializing GCCTL0 after waking up from LPM.

Thanks,

Mitch

Mitch,

thanks for the response. Do GC5 conditions (non-existent FRAM errors) set the UBDIFG? or do we have clear evidence that they don't set the UBDIFG?

From your response, it also looks like the GC5 work around should be re-worded as follows:-

'After LPM wake up, clear GCCTL1.UBDIFG and then reinitialize the GCCTL0 register after the first FRAM access has been completed '.

Is this correct?

In answer to your question, yes, we think we are seeingGC5 issues and we use LPM modes.

Best Regards

Santosh Athuru

Hey Santosh,

The errata states that these errors occur only when the corresponding enable bits are also set.

Given this, I believe that the GC5 conditions set the UBDIFG.

There is a chance that clearing the UBDIFG flag is not necessary since it is not explicitly stated in the errata, but I am recommending to do this to be extra safe. I will reach out to our team and see if we need to update the GC5 errata with this step.

Thanks,

Mitch

i Mitch,

Please confirm and clarify as soon as possible, we will be waiting on this.

I believe the existing Errata workaround for GC5 is not complete and leaves a risk of a PUC or NMI on non-existent FRAM errors, if user doesn't clear the flags in GCCTL1 before enabling the error reporting in GCCTL0.

The GC5 description clearly says that "the FRAM bit error detection may indicate bit errors, even (when) the memory has no failure, after wake up from LPM1/2/3".

The 'indicate' in the above highlighted is via the respective flag bits in GCCTL1 register, right?

If I combine GC5 errata description and FRAM chapter section 7.6 in SLAU367O document, it is clear that the UBDIFG flag will be set if an uncorrectable bit error is detected by the error detection logic.

The term 'Nonexistent' in the Errata for GC5 is what is throwing me off. At any time and especially when waking up from LPM, the error detection logic doesn't know if it just detected a non-existent FRAM error or an existent FRAM error, it just sets the flag on detection - am I right?

GC5:

Section 7.6:- FRAM ECC:

Best Regards

Santosh Athuru

Hi Santosh,

I reached out to our team and will provide more clarification next week. Just so you're aware, I will be on vacation until Thursday of next week. I will give an update when I get back. 

Thank you!

-Mitch

Hi Mitch,

Can someone else help out with updating the response once you all get more details, when you are out. It will really help to have an update early next week.

Best regards

Santosh

Hi Luis, Mitch

thanks for the confirmation and help, when do you plan to have the new Errata released?

Best Regards

Santosh Athuru

Hi Santosh,

I have triggered the process and it usually takes a few days; however, I will keep you updated with the progress.

Regards,

Luis R

Hi Santosh,

Just got an update. The text of the errata was modified but the document online will be updated before the end of the month.

Regards,

Luis R

Hi Luis,

thanks for the update, would it be possible for you to put the GC5 update here, so we can refer till we get the official document?

Best Regards

Santosh Athuru

Thanks Luis.

Best Regards

Santosh Athuru