TMS570LS3137: What happens when the power is interrupted while writing to EEPROM

Hi O.H,

My suggestion is to use the FEE driver. The objective of TI FEE Driver is to provide a set of software functions intended to use a Sector of on-chip Flash memory as the emulated EEPROM.

The EEPROM Emulation Flash bank is divided into two or more Virtual Sectors. Each Virtual Sector is further partitioned into several Data Blocks. A minimum of two Virtual Sectors are required for Flash EEPROM emulation.

The initialization routine (TI_Fee_Init) identifies which Virtual Sector to be used and marks it as Active. The data is written to the first empty location in the Active Virtual Sector. If there is insufficient space in the current Virtual Sector to update the data, it switches over to the next Virtual Sector and copies all the valid data from the other Data Blocks in the current Virtual Sector to the new one. After copying all the valid data, the current Virtual Sector is marked as ready for erase and the new one is marked as Active Virtual Sector. Any new data is now written into the new Active Virtual Sector and the Virtual Sector which is marked as ready for erase will be erased in background.

To generate FEE driver, please enable "FEE" module in HalCOGen first:

Hi QJ Wang,

Thanks for your reply. I'm sorry. My expression was inappropriate.

They use the Flash API to prepare a cleared area (all 0xF) and write data every 16 bytes. I need to check if they are already using the "TI FEE Driver" in the application they are using to write.

I am not familiar with the TI FEE Driver, so let me check.

Is it correct to understanding that by using the ”TI FEE Driver”, it is possible to deal with cases where the power is turned off during writing?

Is it correct to understand that the behavior for such cases is described in "4.12 Power Fail Behavior" in the "TI FEE Driver User Guide"?

Best regards,
O.H

Hi QJ Wang,

Thank you for your answer.

When I suggested FEE Driver to the customer, they said they would consider FEE Driver because they were currently using the Flash API for EEPROM as well.

Just to confirm, when did FEE Driver start supporting TMS570LS3137? I can confirm from HalCOGen that it is supported, but I could not find the model number in the target in the "Software Revision History".

Best regards,
O.H

Hi QJ Wang,

Sorry. I didn't explain it well enough.

They want to clarify when the FEE Driver started supporting TMS570LS3137. They need it to explain internally why they were not using it.

In my opinion, the first version of the datasheet was published in April 2012, and the FEE Driver Use Guide (rev. 1.0) was published in September 2012. From this, I think that TMS570LS3137 has been supported since the FEE Driver was first provided, is that correct?

Best regards,
O.H

Hi QJ Wang,

I have received feedback from a customer, and I'm sorry, could you please allow me to make an additional confirmation?

Is the power interruption countermeasure using the FEE driver also effective in cases where data that has meaning in multiple data is written?
For example, if a power failure occurs while writing 16 bytes x 3 data using the FEE driver, will only the 16 bytes x 2 that were successfully written be updated, while the 16 bytes x 1 that are still being rewritten will have their previous values read out?

Of the four sectors of EEPROM, we use two sectors like a ring buffer. The remaining two sectors are used to store data that is meaningful with multiple data.
Since we use F021, we have a buffer for multiple data in RAM and write data to the two EEPROM sectors alternately. At startup, a sumcheck is performed and if it is determined that a power failure has occurred during rewriting, the normal side is read into the buffer and the application starts.

If the FEE API supports multiple data, and when the power is interrupted before all the data is updated, if all the EEPROMs to be rewritten will read the values before the update, we would like to stop using our software's RAM buffer and two sectors.

Currently, we are not able to use all of the EEPROM area due to the RAM buffer size limitation. We believe that we cannot eliminate the RAM buffer if there is a possibility that the software will be updated halfway through.

Best regards,
O.H

Hi O.H,

O.H said:

Is the power interruption countermeasure using the FEE driver also effective in cases where data that has meaning in multiple data is written?
For example, if a power failure occurs while writing 16 bytes x 3 data using the FEE driver, will only the 16 bytes x 2 that were successfully written be updated, while the 16 bytes x 1 that are still being rewritten will have their previous values read out?

The block status is not updated, so the block is not a valid block. After next initialization, when you read the data from this block, it returns "invalid" or the data of the valid block which has been programmed before the power failure. 

FEE driver doesn't re-write the block after the next init.

Hi QJ Wang,

Thank you for your reply and I'm sorry.

QJ Wang said:

The block status is not updated, so the block is not a valid block. After next initialization, when you read the data from this block, it returns "invalid" or the data of the valid block which has been programmed before the power failure. 

I'm confused because the meaning of "the data of the valid block which has been programmed before the power failure" sounds like the data before the power failure can be recovered. Also, in the TI FEE Driver User Guide, there was no description of the conditions under which "Block Status" becomes "Invalid Block", so please let me check just in case.

As for the operation this time, in order to write a certain data set (16 bytes x 3), I think it will be applied when the power supply is cut off in Step 3 below.

Excerpt from "4.12 Power Fail Behavior" in TI FEE Use guide.
=>If there was a power fail during writing of a block
Block is written in following way
1. Block status is programmed as start program block.
2. Block number and block size are written.
3. Write data of the block.
4. After completion of writing of data, CRC and address of previous block are written.
5. Block status is marked as Active.

At the time of Step 3, the writing of the two 16-byte data is completed.
=>If the power is cut off at Step 3, the "Block Status" of the "Data Block Header" will be "Invalid Block" at the next initialization.
=>The value written at that time (the target bit of the third 16Byte) becomes indefinite.
=>Then, when reading out the data of the target block after initialization, it is returned as "Invalid" and cannot be read out.
=>Or, the data that has already been written (16Byte x2) and the indefinite value (16Byte x1) will be read out.

Is the above idea correct? If so, does the criteria for returning Invalid or reading out incomplete data depend on whether we use the FEE Driver's API or read directly (e.g. CCS Memory Browser function)?

Best regards,
O.H

O.H said:

"the data of the valid block which has been programmed before the power failure"

I mean the valid block already in the sector which is programmed most recently. Because of power failure, the current block is not programmed successfully, it's status is not updated, and the block programmed most recently is still a valid block.

If there is no valid block in the sector, it will be returned as "invalid".