CCS/TMS570LC4357: Fapi EEPROM programing

Hello John,

The EEPROM is flash bank 7, please use 7 for the bank number:

oReturnCheck = Fapi_BlockProgram( 7, 0x8000, (unsigned long)&g_pulUpdateSuccess, g_ulUpdateBufferSize);

BLInternalFlashStartAddrCheck(..) is designed for checking the size of the program flash (bank0 and bank1).

Thanks QJ, this has been a tough one. (yes it was a typo).

After some more effort last night I have been able re reliably create the 'bug' - here a test and the results:

load application from scratch

-> the CC brings up the break at main()

         -> the memory at 0x200000 is incorrect

run the application from the break,

        -> look at the memory browser and the memory is correct - I have not executed the code to program the flash

press key on UART to initiate the FLASH programming sequence

the CC breaks before executing the code to program

      -> the memory browser has the old view of the correct code (auto updated)

I manually refresh the memory browser from the brake point

      -> it shows incorrect code

I step through the programming 

  ->  the memory browser shows incorrect values (even with manual refreshes)

I let the code composer run (no break point)

    -> and refresh the memory browser - it shows correct values

I pause CC

    -> the memory browser shows incorrect values

I continue CC and refresh the memory browser

    ->  it shows correct values

I pause CC

    -> the memory browser shows incorrect values

I continue CC and refresh the memory browser

    ->  it shows correct values

What are your thoughts?

2502.halcogen FEE config.docxHere is the config from HALCoGEN. They are the default settings. Do you see any issues?

I put in _cacheDisable_(); as per your suggestion. 
 
No change... still see the two different views.

Do you see an issue with the HALCogen FEE configuration?

Here is the code I am using from the example


uint32_t g_pulUpdateSuccess[] = {0x00000000, 0x11111111, 0x22222222, 0x33333333, 0x44444444, 0x55555555, 0x66666666, 0x77777777,0x88888888,0x99999999,0xAAAAAAAA,0xBBBBBBBB,0xCCCCCCCC,0xDDDDDDDD,0xEEEEEEEE,0xFFFFFFFF};
uint32_t size;

size = BLInternalFlashFirstSectorSizeGet();
size = BLInternalFlashSizeGet();
size = BLInternalFlashStartAddrCheck(0x200000, 64);
uint16_t oReturnCheck;
oReturnCheck = Fapi_BlockProgram( 1, 0x200000, (unsigned long)&g_pulUpdateSuccess, 64);

Hi John,

You use F021 Flash APIs to erase and program the Bank 7 (EEPROM) and rather than the FEE drivers. If you want to use the Bank 7 to store data. I recommend you to use the FEE driver.

The configuration for FEE in your doc looks good to me. The sample code for write data to FEE and read data from FEE:

/* USER CODE BEGIN (0) */

#include "ti_fee.h"

/* USER CODE END */

/* Include Files */

#include "HL_sys_common.h"

/* USER CODE BEGIN (1) */

uint16 u16JobResult,Status;

Std_ReturnType oResult=E_OK;

unsigned char read_data[100]={0};

uint8 SpecialRamBlock[100];

unsigned char pattern;

uint16 u16writecounter;

unsigned int  FeeVirtualSectorNumber;

unsigned char VsState, u8EEPIndex;

unsigned char u8VirtualSector;

uint8 Test_Recovery;

uint8 Test_Cancel;

void delay(void)

{

unsigned int dummycnt=0x0000FFU;

do

{

dummycnt--;

}

while(dummycnt>0);

}

/* USER CODE END */

/** @fn void main(void)

*   @brief Application main function

*   @note This function is empty by default.

*

*   This function is called after startup.

*   The user can use this function to implement the application.

*/

/* USER CODE BEGIN (2) */

/* USER CODE END */

void main(void)

{

/* USER CODE BEGIN (3) */

unsigned int BlockNumber;

unsigned int BlockOffset, Length;

unsigned char *Read_Ptr=read_data;

unsigned int loop;

/* Initialize RAM array.*/

for(loop=0;loop<100;loop++)SpecialRamBlock[loop] = loop;

/* Initialize FEE. This will create Virtual sectors, initialize global variables etc.*/

TI_Fee_Init();

do

{

TI_Fee_MainFunction();

delay();

Status=TI_Fee_GetStatus(0 );

}

while(Status!= IDLE);

/* Write the block into EEP Asynchronously. Block size is configured in ti_fee_cfg.c file. Default Block size is

  8 bytes */

BlockNumber=0x1;

TI_Fee_WriteAsync(BlockNumber, &SpecialRamBlock[0]);

do

{

TI_Fee_MainFunction();

delay();

Status=TI_Fee_GetStatus(0);

}

while(Status!=IDLE);

/* Write the block into EEP Synchronously. Write will not happen since data is same. */

TI_Fee_WriteSync(BlockNumber, &SpecialRamBlock[0]);

/* Read the block with unknown length */

BlockOffset = 0;

Length = 0xFFFF;

oResult=TI_Fee_Read(BlockNumber,BlockOffset,Read_Ptr,Length);

do

{

TI_Fee_MainFunction();

delay();

Status=TI_Fee_GetStatus(0);

}

while(Status!=IDLE);

/* Invalidate a written block  */

TI_Fee_InvalidateBlock(BlockNumber);

do

{

TI_Fee_MainFunction();

delay();

Status=TI_Fee_GetStatus(0);

}

while(Status!=IDLE);

/* Format bank 7 */

TI_Fee_Format(0xA5A5A5A5U);

   while(1);

/* USER CODE END */

}

I am trying to write to the program memory in Bank 1 to program the Flash, not Bank 7 (see memory address 0x200000).

Which interface is correct? Are 'blocks' the same as 'banks', and if not how do I translate between them?

The programming also appears to be intermittent, some times it is successful, sometimes not.

I can reliably generate a condition in which code composer provided two different views of memory.

I understand something may not be configured correctly, but this is a CC bug and needs to be escalated.

Other than the bootloader example code is there a simple few limes of code that we could both try and see if your hardware and mine are operating correctly?

Hello John,

The diagrams in your doc show the FEE configuration. I thought you switched to FEE for storing data. In FEE driver, the block is a group of data.

If you erase/program the Bank 0 and Bank 1, you need to use the F021 API but the FEE driver which is only used for bank 7 (used as an emulated eeprom).

Your code looks good:

uint32_t g_pulUpdateSuccess[] = {0x00000000, 0x11111111, 0x22222222, 0x33333333, 0x44444444, 0x55555555, 0x66666666, 0x77777777,0x88888888,0x99999999,0xAAAAAAAA,0xBBBBBBBB,0xCCCCCCCC,0xDDDDDDDD,0xEEEEEEEE,0xFFFFFFFF};

uint32_t size;

size = BLInternalFlashFirstSectorSizeGet();

size = BLInternalFlashSizeGet();

size = BLInternalFlashStartAddrCheck(0x200000, 64);

uint16_t oReturnCheck;

oReturnCheck = Fapi_BlockProgram( 1, 0x200000, (unsigned long)&g_pulUpdateSuccess, 64);

But you need to erase the sector the sector first before your program the data to this sector.

I have added the erase and there are still errors in the programming.

I have tried another Hercules TMS570LC43x board with the same results.

Here is some information that may be helpful. I have a break point at the following line of code:

Fapi_issueProgrammingCommand((uint32_t *) dst,( uint8_t *)src,(uint32_t) bytes,0,0,Fapi_DataOnly); //Fapi_AutoEccGeneration);

As I am programming 64 bytes (32 each call) the line is executed twice. The first time the line is stepped over the Code Composer correctly moves to the next line of code. The second time the line is stepped over the Code Composer does  not return. If I press the 'pause' button the code is executing back at the key input loop. This can be reliably repeated.

Here are the results from the suggested lines of code.7382.Errors in flash step sequence.docx

We are getting closer..

I have modified Fapi_issueProgrammingCommand from:Fapi_DataOnly to: Fapi_AutoEccGeneration

I also put test code in to do the following:

- prior to a write to see if the value is correct at the location (@ 0x200000)

- perform a write (@ 0x200000)

- after the write test the value to see if its correct (@ 0x200000)

- issue a second write at a different location (@ 0x200120)

- test the original location again (@ 0x200000)

Here are the results (stepping through the code one line at a time):

The location was incorrect when first tested

When the 1st erase/write was performed the Memory Rendering is now correct for all 64 locations (@ 0x200000)

The 2nd erase/write was performed at the other location the Memory Rendering is correct at (0x200120) but now corrupted at (0x200000) - it was neither erased now cleared - just messed up

I commented out the second erase and re-ran the code

The memory was incorrect when entered, correct on the first write and stayed correct on the second write

I commented out both Fapi_BlockErase requests - both memory at both locations remain correct

Also the 2nd execution of  Fapi_issueProgrammingCommand no longer messes up the Code Composer step process..

Looking closer, the 1st execution of the erase (targeting 0x200000) was corrupting the second location of memory (at 0x200120) even though the call was made to 0x200000...

Here is the test code used:

   uint32_t *src;

   src = 0x200000;

   status = *src;

   if (status ==  0xea0004bd)

     src++;

   else

     src--;

   uint32_t Success[] = {0xea0004bd, 0x00000000,

   0x00000000, 0x00000000,

   0x00000000, 0x00000000,

   0x00000000, 0x00000000,

   0x4605b538, 0x2d06460c,

   0x2d08d005, 0x2d0ed003,

   0x2005bf18, 0x2010d108,

   0xfa34f000, 0x60044803};

   status = Fapi_BlockErase(1, 0x200000, 0x2000);

   status = Fapi_BlockProgram( 1, 0x200000, (unsigned long)&Success, 64);

               src = 0x200000;

               status = *src;

               if (status ==  0xea0004bd)

                   src++;

               else

                   src--;

   int16_t i;

   for (i=0;i<64;i++)

       pData[i] = 0xFFFFFFFF;

   uint16_t oReturnCheck;

   //oReturnCheck = Fapi_BlockErase( 1, 0x200120, 64);    <--- was corrupting 0x200000)

   oReturnCheck = Fapi_BlockProgram( 1, 0x200120, (unsigned long)&pData, 64);

               src = 0x200000;

               status = *src;

               if (status ==  0xea0004bd)

                   src++;

               else

                   src--;

What is the intended result of the block clear (as it relates to the cleared data pattern  - i.e. all 0's or 1's)?