TM4C1233H6PZ: Data loss of TM4C1233H6PZ EEPROM

Hi Charles,

Thank you for replying me.

Here is the code.

void main(void)

{

     /*****************************************/

     /****************變數宣告********************/

     int LCM_counter= 0x00;

     unsigned char function_selection = 0;

     /*****************************************/

     /****************Initialize***************/

     Initializing();   /* System Initialize */

     LCM_Reset();  /* LCM Initialize */

     /******************************************/

     /****************EEPROM********************/

     //EEPROM_Reset(); /* RESET EEPROM */

     EERPOM_Initializing();

…………………

}

void EERPOM_Initializing(void)

{

     /**********Please Look Up EEPROM_ADDRESS, If You Want Know More Detail */

     unsigned long coefficient_buffer = 0x00;

     unsigned char EEPROM_First = 0;

     unsigned char char_buffer = 0;

     unsigned int int_buffer = 0;

     // Reads data from the EEPROM

     EEPROM_Read_One_Byte(&EEPROM_First, 0, 1);

     EEPROM_Read_Two_Byte(&int_buffer, 1, 1);

     if(int_buffer >  (VOLTAGE_COE_MAX * 1000000))

     {

         EEPROM_First = 0x00;

     }

     else

     {

         int_buffer = 0;

     }

     if(EEPROM_First != 1)

     {

         EEPROM_First = 1;

         // Erases the entire EEPROM. This isn’t strictly necessary because, unlike flash, EEPROM does not need to be erased before it is programmed.

         // But this will allow us to see the result of our programming more easily in the lab.

         EEPROMMassErase();

         /***************使用指令更新後，全部內容皆為0xFF*****************/

         EEPROM_IC_CHIP_ERASE();    /*******ERASE MEMORY IC********/

         /*****************************第一次使用********************************/

         char_buffer = EEPROM_First;

         EEPROM_Save_One_Byte(&char_buffer, 0, 1); /* Set 1 */

         /*****************************第一次使用********************************/

         /*******************************語言***********************************/

         char_buffer = Language_default;

         EEPROM_Save_One_Byte(&char_buffer, 0, 2); /* Language: English */

         /*******************************語言***********************************/

         /*************************************電瓶種類*****************************************************/

         char_buffer = Battery_Type;

         EEPROM_Save_One_Byte(&char_buffer, 0, 3);

         /*************************************電瓶種類*****************************************************/

         /*************************************溫度範圍*****************************************************/

         char_buffer = Temperature;

         EEPROM_Save_One_Byte(&char_buffer, 0, 4);

         /*************************************溫度範圍*****************************************************/

         /****************************電壓校正 Voltage_Adjustment_ch0****************************************/

         int_buffer = Voltage_Coefficient_ch0;

         EEPROM_Save_Two_Byte(&int_buffer, 1, 1); /* Set 4003 */

         /****************************電壓校正 Voltage_Adjustment_ch0****************************************/

         /****************************電壓校正 Voltage_Coefficient_ch1****************************************/

         int_buffer = Voltage_Coefficient_ch1;

         EEPROM_Save_Two_Byte(&int_buffer, 1, 2); /* Set 4003 */

         /****************************電壓校正 Voltage_Coefficient_ch1****************************************/

…………………….

}

Before the first use of the MCU, the value of EEPROM is 0xFF.

At the first use, 1st byte set to 0x01 & 5th and 6th bytes set to 0x11(for instance).

As you can see in the code, if values of 1st, 5th, & 6th are not the value above, the program will reset the value.

I know I should not do this, I should be left whatever values they are, but.....I did it.

The question is it happened on a production product and about 2/5000pcs that EEPROM in M4 MCU are rested after 2 years used in customers hand.

So I am wonder why....

My coworker found this text in a sample code....

//If the supply voltage is

//! unstable when this return code is observed, retrying the operation once the

//! voltage is stabilized may clear the error.

Maybe it was caused by voltage unstable.

I will try it first and let you know if it is the cause.

Thank you

CHEN

Hi,

If you have 2pcs with problem in 5000 pcs, it is normally to chech the number of write cycles performed in two years instead of your code. That number can be exceeded and it is normal the chip failure. We had a similar problem with such kind of memories, chip failure after 2...6 years, but the number of write cycles was exceeded, so we reduced the number of writes. If you check and over-write a location each time you write on another one, then for sure that is the cause.

These memories are higly reliable for normal use, your practice to check each time and over-write is unusual and unnecessary in my opinion.

For 2pcs, just replace them with new ones.

Albeit you are correct, I would not rule out low voltage / power fail issues.

I made a lot of unnerving experiences with devices supposed to erase/write EEPROM after a mains power fail, living from a cap charge. EEPROM or Flash erase/write can take millions of clock cycles, and increases power consumption. FRAM/MRAM would be a safer alternative.

Hi,

The o/p uses 25LC512 chip, no Tiva api apply here...

Hi,

25LC512 is a 64Kx8 , so internal eeprom is way too low for user's needs.

As for FRAM, I am not sure about the price, on production line even 2c difference does matter.

That depends. The TM4C itself is not quite the smallest&cheapest choice, so FRAM might be an option.

Fortunately not our decision ... ;-)

Bruno Saraiva said:

By the way, being the problematic IC not even this forum's MCU, I guess we're wondering way too much! I have this TM4C MCU which receives tire pressure data from 4 different tires on a car - and recently, the Firestone front-right tire has started going flat too often. Can you gents help me figuring it out?

Had been working on a project for a customer of my former company that was related to such tyre pressure measurement systems. They used (ughh) MCP PIC16 controllers at that time, and one of the ISM bands (433 / 866 / 915MHz). The transmitter part (measurement and transmission) was a one-man assembler code project ... That company of mine had other automotive customers later on, where I learned many other things as well.

And ever since then, I only buy cars with the least amount of electronics.

But to your issue - I'm sure it has nothing to do with that measurment system, but rather the valve or the tyre. The problem is - that sensor is usually incorporated in this (schrader) valve. Replacement might get a bit expensive.

Thiago Borba Onofre said:

I dont have experience, but 2 problems in 5000 boards can be considered a problem?

That depends on the customer. Some do send back whole batches of thousands if they find a problematic one.

Thiago Borba Onofre said:

How often do you access the memory? Did your code wrote more than 100k times in your memory, if so it may not work anymore...

IMHO wearout seems less likely. Unless mostl erase/write accesses are happen at the maximal temperature, the 100k represents the guaranteed lower limit. For every drop of temperature by 10 deg. Celsius, you can multiply the average number by two.

I dealt a lot with corrupted Flash/EEPROM settings in one of my former companies, and all were related to either bad hardware design or ignorant ("too optimistic") SW design. The erase/write takes milliseconds per cell, with increased power draw. If you pull the power in the middle, you get the observed result ...

I think the OP can test this by forcing a power-off during erase/write. If that corrupts a significant number of devices, a HW redesign/fix might be the way to go.

Hi f.m. thank you for your answer!

When you say "bad hardware design or ignorant ("too optimistic") SW design", how did you overcome those problems? Where did you learn how to do better HW and SW designs? Did someone teach you or is it more like time and experience? 

Regards!

Thiago Borba Onofre said:

When you say "bad hardware design or ignorant ("too optimistic") SW design", how did you overcome those problems?

You might not like my answer - by leaving this company.

Thiago Borba Onofre said:

Where did you learn how to do better HW and SW designs?

I had a bit of experience at the time, but was relatively new at the company (less than 3 years, compared to 10 .. 15 years of some 'deciders'), and moved in from abroad. And more imortant, it dealed with a mass product, where hardware costs trumped (no pun intended) everything. About one third of the whole code involved hardware bugfixes and workarounds. As a kind of 'outsider', criticizing a project and proving correct at the end is not quite carreer-enhancing ...;-) And since the company - or it's development department - did not want to change, I did. I moved on to a company with more focus on SW design, and less on minimizing HW costs.

Thiago Borba Onofre said:

Did someone teach you or is it more like time and experience? 

Basically, I learned most by myself. Being teached just a programming language at university (which I knew already at that time), I just did a lot of projects, both hobby and commercially, i.e. the companies I worked for. Learning from one's own mistakes definitely proves helpful.

Bruno Saraiva said:

Chen Hsiao, 

How often do you access the memory? Did your code wrote more than 100k times in your memory, if so it may not work anymore... 

You should may check the microcontroller errata... maybe there is something there...

Can you replace those boards until you figure out what is the main problem? 

I dont have experience, but 2 problems in 5000 boards can be considered a problem?

Thiago B. Onofre

Chen Hsiao said:

EEPROM Read: 49times & Write: 11 times per use.

Read access is no problem, the "write" one is.

Chen Hsiao said:

Write: 11 times per use.

What means "per use" ?

Can you break it down to writes per hour (or per day), and possibly per cell ?

The most often written cell/block would break down first.

If this numbers stay well below 10.000 for those faulty parts, you can probably rule out a wear-off problem at first.

As mentioned before, an erase/write takes milliseconds. This is quite a long time for a MCU with 80MHz core clock.

The problem is - what happens to the MCU and the EEPROM when a write access is interrupted by a power-off ? Probably you have some electrolytic cap on your board, holding Vcc up for a few milliseconds. I guess it will not hold your system up long enough to finish the write access.

I was involved in a project that dealt with similar issues. It had to save several values to Flash/EEPROM after power-off. This device was mains powered (240V), and had a electrolytic cap designed to power it long enough for this write process, including some safety margin. And of course, it had a sensor input to detect a power fail.

Something along this line would be my suggestion. You will probably need to detect a power-off, to avoid an excessive number of write accesses. And you probably need the power (cap storage) to finish at least one erase/write access before total blackout. That would of course involve a hardware redesign.

A second option would be to store multiple versions of your data in a successive order, including some checksum, and fall back to the last "proper" set if you detect a corruption. No hardware change involved, but quite a non-trivial software change.

Or, you can accept to live with this current issue.