This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi there,
Context:
I have been struggling with a problem for a few days now. I am writing an application for RM42L432 based on FreeRTOS. The base libraries were generated using Halcogen.
The application needs to store permanent configuration values and I am using the Flash EEPROM Emulation for that purpose.
The FEE driver is configured to use 16 blocks of 8 bytes. See the attached ti_fee_cfg.h/c files below.
Problem:
I am trying to run the following sequence:
Std_ReturnType o_result=E_OK; uint16 eeprom_status; TI_Fee_Init(); do { TI_Fee_MainFunction(); eeprom_status=TI_Fee_GetStatus(0); } while(eeprom_status!= IDLE); uint8_t data_zero[8] = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; TI_Fee_WriteSync(1, data_zero, 8); uint8_t data_one[8] = {0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; TI_Fee_WriteSync(1, data_one, 8); uint8_t dread[8]; o_result=TI_Fee_Read(1,0,dread,8); do { TI_Fee_MainFunction(); delay(); eeprom_status=TI_Fee_GetStatus(0); } while(eeprom_status!=IDLE);
I was expecting to get dread = {0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
However, I am getting dread = {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
Investigated so far:
1 - Memory state after write(data_one)
I monitor the values in memory and I come to the conclusion that the second write-array operation is not being performed. This is the memory state (monitored in Code Composer's memory browser) right after the execution of write(data_one):
If I am not mistaken, I can see clearly the data_zero being written to a block, but I don't see data_one being written at all.
2 - Memory state after write(data_one) modified
If I replace the values in data_one by, say:
I get the correct result and at the end of the code execution looks like this:
That made me think that the problem is in the value being written.
3 - Disabling Checksum
I came across the application report SPNA139 and I thought that the issue could be related to the checksum calculation. So, I disabled the checksum in ti_fee_cfg.h by setting
Files:
Hello Rafael,
The FEE driver uses the Fletcher16 algorithm to calculate the checksum. The Fletcher checksum cannot distinguish between blocks of all 0 bits and blocks of all 1 bits. [0x00, 0xFF, 0x00, 0x00, 0x00, 0x00,0x00,0x00] and [0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00,0x00] have a same checksum (0xFFFF). If checksum is enabled, the block will not be written if the checksum of the new data is the same the checksum of the old block data.
Hi Wang,
Thanks for your detailed response.
What would be the best option to work around this issue? In my application, I cannot assume that I won't be writing 0xFF after 0x00 (or vice versa). From what I understand, the piece of code from ti_fee_writeSync.c that I added in my original code is there to prevent re-writing data with the same CRC to flash. What would be the implications of bypassing that test?
Do you see any other solution other than deactivating the checksum calculation?
Thanks in advance,
Rafael Duarte
Hello Rafael,
The checksum is used to avoid rewriting the block with the same data. This checksum is not used for block reading. My suggestion is to disable the checksum.