TMS570LS1227: EEPROM issue after several write/read operation, in FreeRTOS app

Hi there,

I am using a TMS570LS1227 in an embedded project. I am using FreeRTOS V8.2.0 on it.

The project is basically composed of 3 tasks:

int main(void)
{
/* USER CODE BEGIN (3) */
    // init des modules
    gioInit();
    spiInit();
    sciInit();
    vimInit();
    adcInit();
    TI_Fee_Init();
    _enable_interrupt_();
    _enable_IRQ();

    xTaskHandle xAcqTaskHandle, xAsyncComTaskHandle, xSyncComTaskHandle, xSetResetTaskHandle;
    if (xTaskCreate(vAcqTask,"vAcqTaskHandle", configMINIMAL_STACK_SIZE*4, NULL, 1, &xAcqTaskHandle) != pdTRUE)
    {
        while(1);//Task could not be created
    }

    if (xTaskCreate(vAsyncComTask,"vAsyncComTask", configMINIMAL_STACK_SIZE*2, NULL, 1, &xAsyncComTaskHandle) != pdTRUE)
    {
        while(1);//Task could not be created
    }

    if (xTaskCreate(vSyncComTask,"vSyncComTask", configMINIMAL_STACK_SIZE*5, NULL, 1|portPRIVILEGE_BIT, &xSyncComTaskHandle) != pdTRUE)//portPRIVILEGE_BIT
    {
        while(1);//Task could not be created
    }
    //Start Scheduler
    vTaskStartScheduler();
    // Run forever
    while(1);
/* USER CODE END */

    return 0;
}

The Acq task is in charge of acquiring data from sensors.

AsyncCom  task is in charge of sending data to PC.

SyncCom task in in charge of receviing messages form PC, update parameters in EEPROM and answer to PC.

As you can see, all 3 tasks have the same priorities, but I added portPRIVILEGE_BIT to the SyncCom task because it was necessary to have the eeprom write function working.

Modification to EEPROM are made using the following function I wrote:

void delay(void)
{
    unsigned int dummycnt=0x000FFFU;
    do
    {
        dummycnt--;
    }
    while(dummycnt>0);
}

void EEPROM_readValue(uint8_t* buffer_o, unsigned int length, uint8_t block_number) {
    TI_Fee_ReadSync(block_number, 0, buffer_o, length);
    delay();

}

void EEPROM_writeValue(uint8_t* buffer_i, uint8_t block_number) {
    TI_Fee_WriteSync(block_number, buffer_i);
    delay();
    TI_Fee_MainFunction();
}

uint8_t tmp[576]; // max block size used is 576 bytes
void EEPROM_modifyParameter(uint8_t* parameter, unsigned int parameter_size, unsigned int offset, uint8_t block_number) {
    const unsigned int max_block_size = 576;
    //1) get corresponding block from EEPROM and copy to tmp
    EEPROM_readValue(tmp, max_block_size, block_number);

    //2) modification of tmp
    memcpy(tmp+offset*sizeof(double), parameter, parameter_size);

    //3) rewrtie block with tmp
    EEPROM_writeValue(tmp, block_number);
}

The issue I am facing is the following: everything worked well for a while (I could send parameters from the PC, they were written in the EEPROM. No problem after power-off: paramaters were correctly read in EEPROM and data persistance was OK)

But yesterday, it suddenly stopped working: the Ti_Fee_WriteSync function did not work anymore (stuck in module state= BUSY). This happened on a PCB home made board. I tried the same code on the evaluation HerculeLaunchpad, and same result: working well for a while, but after multiple write of the parameters, Ti_Fee_WriteSync broke.

I was loading the program using CCS, with the option in the "debug" tab specifying to not erase FlashBank 7, in order to keep my parameters saved between 2 program load.

Problem was solved by resetting this paramater to erase all flash sectors, but this is not satisfying: I want the product to be usable without having to reflash the code to "repair" the flash...

I have absolutely no idea of what is hapenning here.

Last pieces of information, in case it helps:

- interruptions (gio, uart rx) can trigger while the SyncCom task is performing read/write operation in EEPROM. however, this task is the only one to access EEPROM.

- for spi issue reasons, i had to down the VCLCK1 by increasing divider to 7.

attached the corresponding halcogen configuration