TM4C123GH6PZ Brown-Out Reset

Hello af36,

If you are running TM4C123 revision 6 silicon, then one of the issues is the EEPROM. If the device were to be working below the BOR threshold when an EEPROM access occurs, then there can be a potential lock out issue.

Regards
Amit

af36 said:

) running 24/7 reliability cycling, and just recently 2 of them started having BOR events about twice a day. 

Just to note, I have found the '123 BOR to be very sensitive to noise. Had to disable it.

Robert

Thank you Amit and Robert for the fast responses. I have some additional questions though.

We cannot guarantee silicon revision. I read the errata MEM#03 on the EEPROM write corruption, but it looks to me like this corruption can occur with any BOR event regardless of whether it is configured to generate an interrupt or reset. '123 link here: www.ti.com/.../spmz849f.pdf

I do note that the '129 MEM#03 errata is more explicit, stating that it only occurs if configured for a simulated POR sequence: www.ti.com/.../spmz850f.pdf

Can you please clarify?

Fortunately, we do not write to the EEPROM while the system is running for the '123. Unfortunately, we frequently write to the EEPROM on a different board in the same system that utilizes the '129, but we have never seen the issue on this part. I do see that the BOR threshold on the '129 is much more forgiving (2.95V max).

I also note that the description of the PBORCTL register for the '123 states the thresholds are based on simulation only and are not characterized and subject to change. The '129 does not have this disclaimer. This makes me think that changing the BOR reset to an interrupt is probably the way to go.

We do use an external voltage supervisor, but it does not trigger a reset until the voltage drops to 2.00V +/- 2%.

I am thinking it is acceptable to change to a BOR interrupt on the '123 given the Table 24-10 disclaimer, but keep the BOR reset on the '129 because it does not include the disclaimer. Unless it is just an oversight, and the '129 can function down to the POK thresholds as well.

Thanks again.

Also, I think the SPMA065 differences between TM4C's (www.ti.com/.../spma065.pdf) may have a typo. It states in Section 3.4 that the default brown-out operation for the '123 is "Interrupt" versus "POR" for the '129. It looks to me like both the '123 and '129 default to a brown-out POR.

Hello af36,

Any reset breaks the state machine which handles the EEPROM data handling. Also the flash operation may be affected by a reset causing some bits to be written while other bits not to be written.

TM4C129x does not have the more trouble some issue of MEM#04 or MEM#05. However a sharp voltage fall may still corrupt the data word in EEPROM while it is being written to the flash.

Regards
Amit

Amit,

Thanks for lightning quick response! And sorry that I missed MEM#04 specifically. Not sure how I missed that.

For clarification's sake, when you say any reset:

Amit Ashara said:

Hello af36,

Any reset breaks the state machine which handles the EEPROM data handling. 

do you mean that if we change the BOR functionality to an interrupt, we do not have the issue of MEM#04?

af36 said:

For clarification's sake, when you say any reset:

Any reset--> Power loss, watch dog (and surely you are using a watch dog), BOR (if not turned off), software reset, external reset (and maybe a separate possibility from JTAG?).

Basically, unless EE is used under very controlled conditions there is a possibility it will brick the processor. Check the other EE errata as well.

Robert

Hi Amit,

In re-reading this response:

Amit Ashara said:

 
We may have the issue if the voltage drops fast enough. That is why I would prefer to have an external voltage supervisor.

I am a little confused. How would an external voltage supervisor prevent this issue? It seems to me that an external voltage supervisor driving the external reset input on the '123, which would have its own hysteresis and likely be less sensitive, would not prevent the issue. If the voltage supervisor does reset the '123, it would be at the external reset which per MEM#04 would also cause the problem.

What am I missing?

Thank you.

Hello af36,

Yes, that is true. But if you note, the issue is fixed on Revision 7. So even though the EEPROM write/erase may not succeed, the device will still remain functional.

Regards
Amit