CCS/RM48L952: TI Fee Read Async Operation Question

Hello,

Have you configure the EEPROM wait state (EEPROM_CONFIG register)?

The RWAIT value is used to define the number of wait states for the program memory flash. The EWAIT value is used to define the number of wait states for the data flash in bank 7. You can use same value of RWAIT for EEPROM.

Hello QJ Wang,

is this register part of the TI Fee initialization as I assume everything connected to the eeprom is inside the Fee driver lib. The eeprom wait states configuration is in the Flash driver init, I guess and I didn't touch there anything as the examples from Halcogen were running to a certain degree.

This is my current procedure. As already mentioned above I have two virtual sectors, so I start filling the first active virtual sector with "dummy data" even if I have less data blocks. I am writing dummy data with the same block number (blocknumber 1-16 several times in a loop) until the first virtual sector is completely filled. When I perform the readback here before the next virtual sector has been activated, I can readback everything correctly via TI_Fee_Read(), even when the same block number has been written several tmes with different data content.

When the switch to the next virtual sector is perfomed and I continue to write data on the eeprom, I can evalute write activities on the second virtual memory sector locations. But if I now read the data back via TI_Fee_Read(), I always get as a result that the job was not accepted and therefore the buffer is not filled with valid data.

I don't know if I catched some steps wrong or if I need to invalidate data manually when jumping between different virtual sectors.

During the debugging sessions, I always jump into this part of the TI_Fee_Read() in fee_read.c while one virtual sector has been completely filled with dummy data (marked yellow).

if((oResult == (uint8)E_NOT_OK)||(TI_Fee_GlobalVariables[u8EEPIndex].Fee_u16JobResult == BLOCK_INVALID)||
(TI_Fee_GlobalVariables[u8EEPIndex].Fee_u16JobResult == JOB_FAILED))
{
/* no other operations are in progress, change the module state if it is initialized */
if((TI_Fee_oStatusWord[u8EEPIndex].Fee_StatusWordType_ST.EraseImmediate == 0U) &&
(TI_Fee_oStatusWord[u8EEPIndex].Fee_StatusWordType_ST.InvalidateBlock == 0U) &&
(TI_Fee_oStatusWord[u8EEPIndex].Fee_StatusWordType_ST.WriteAsync == 0U)&&
(TI_Fee_oStatusWord[u8EEPIndex].Fee_StatusWordType_ST.WriteSync == 0U)&&
(TI_Fee_oStatusWord[u8EEPIndex].Fee_StatusWordType_ST.Read == 0U)
)
{
/* Restore the module state */
TI_Fee_GlobalVariables[u8EEPIndex].Fee_ModuleState = ModuleState;
TI_Fee_oStatusWord[u8EEPIndex].Fee_StatusWordType_ST.Read = 0U;
#if(STD_OFF == TI_FEE_POLLING_MODE)
TI_FEE_NVM_JOB_ERROR_NOTIFICATION();
#endif
}
}

Hi Mux,

Yes, the EEPROM wait state is defined in setupFlash() in system.c: 

/** - Setup flash access wait states for bank 7 */

FSM_WR_ENA_HL = 0x5U;

EEPROM_CONFIG_HL = 0x00000002U
| (uint32)((uint32)3U << 16U) ;

/** - Disable write access to flash state machine registers */

FSM_WR_ENA_HL = 0xAU;

When you write the data to the VS1, the driver checks if there is enough space in VS1 for the data. If the space is not enough, the driver copy all the valid blocks from VS1 to VS2, and write the current data to VS2. Those procedure is done automatically by the driver. If the data is not wrote correctly, an error should be returned (E_NOT_OK).

You can check the block status in memory browser. The block may not be valid. If it is invalid, you need to re-write this block again.

Hello QJ Wang,

I have checked that configuration and it is the same as you have.

I am using a simple blockset and writing the data continously into the EEPROM in order the see the behaviour when one or both virtual sectors are full. When I switch to the memory browser with "continous refresh update" activated, there is point where the whole data ist set to BAD for some reason. I am only using the example code provided by Halcogen but I extended the reference example to not invalidate and format the data as in the example.

So in my case, both virtual sectors get full at a certain point, I don't know if this is the trigger when I see only BAD data for a short moment till the data is written again into the EEPROM.

Moreover, it looks like the FEE API consumes some time between those swaps and copy operation as well as erase operation. I thought that the toggling between the virtual sectos is smoother.

Do you know what happened here and what went wrong? Did I miss some steps? Do I need to invalidate data when both virtual sectors are full? The user guide doesn't indicate anything as the whole complexitiy is abstractedin the TI Fee driver library and its usage is straight forward. Are there some technical limitations?

Does TI have some benchmarking when those swap and copy operation are perfomed? For the erase time, I guess you can reference to the electrical data sheet for the RM48 chip.

Hi Mux,

Both virtual sectors should not get full at the same time. The total size of the data blocks should be smaller (or much smaller) than the virtual sector size. When 2 virtual sectors become full, did you check the status of these two sectors in the sector header?

 You are correct. It takes long to erase the sector, may be up to seconds in worst case. I did a lot of test before by writing data to the sectors continually for hours, and did not see this kind of issue. 

BTW, which rev HALCoGen are you using? The latest one is 4.07.01. Also please check the known issues in HALCOGen FEE drivers:

http://www.ti.com/lit/ml/spna203/spna203.pdf

Hello QJ Wang,

thanks for the feedback. Regarding the latest version of Halcogen, I got to this point by accident as it was mentioned by other users on the e2e forum. 

The jump into the if clause (yellow marked) was fixed with the latest version of halcogen, but I am still struggling a little bit regarding the issue when both virtual sectors are full or a copy swap from one to another virtual sector is perfomed as I am continously measuring the needed time for this action. Simple write and reading actions are quite fast, but when the virtual sectors get full and an internal copy/erase as well as a swap is perfomed on the EEPROM, it takes some time. 

I would like to know how do I solve this issue in fine way with the help of your current API (Fee User Guide). Your example on Halcrogen just provides some basic functionalities, but there is no procedure which explains how to deal with that "time consuming" process when the copy/swap and erase is performed as I would not like to block the CPU or to call the TI_Fee_MainFunction for approx. 20000 iterations until the status (TI_GetStaus()) is updated to leave the loop

Is there something you can suggest to handle that scenario easily?