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.

RM42L432: Failing to write 0xFF and 0x00 values to FEE with enabled Checksum in RM42L432

Part Number: RM42L432
Other Parts Discussed in Thread: HALCOGEN

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:

uint8_t data_one[8] = {0x00, 0xFF, 0x55, 0x00, 0x00, 0x00, 0x00, 0x00};

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

#define TI_FEE_FLASH_CHECKSUM_ENABLE STD_OFF
and ran the original code again. This time, I got the following values in memory:
So, with checksum disabled, it seems to work as well.
I did a step by step execution and noticed that in case (1), the write operation gets in this if statement:
This causes the writing operation to be skipped. Commenting this if statement also fixes the issue (just like disabling the checksum does).
Questions:
- I am not sure exactly how to fix the issue. I understand that changing ti_fee libraries is not a good idea. Also, for my application disabling the checksum might also not be a good idea. So, am I missing something? 
- Is this problem related to SPNA139? If yes, is there a way of enabling the all 0's/1's feature that is mentioned in this document? I couldn't find much information about it.

Files:

1830.ti_fee_cfg.c

0647.ti_fee_cfg.h

  • 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.

  • You will see that checksum0 and checksum1 = 0xFFFF. This is the weakness of Fletcher16 checksum algorithm.

  • 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.