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.

TMS570LC4357: Getting example_TI_Fee_Write_Read.c built in a project

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

I am trying to build a test program that accesses (fake?) EEPROM.  I see that example_TI_Fee_Write_Read.c does that and am incorporating it in a project.  I get the following error:

>> Compilation failure
source/subdir_rules.mk:9: recipe for target 'source/example_TI_Fee_Write_Read.obj' failed
"C:\Users\plu\Documents\TMS_XL2-570LC43-Examples\TMS570LC43_FEE\include\fee_interface.h", line 88: fatal error: cannot open source file "fee_cfg.h"
1 catastrophic error detected in the compilation of "../source/example_TI_Fee_Write_Read.c".
Compilation terminated.
gmake: *** [source/example_TI_Fee_Write_Read.obj] Error 1

**** Build Finished ****

which stems from fee_interface.h:

#include "ti_fee_cfg.h"

#if(TI_FEE_DRIVER == 0U) /* Include following macros only in Autosar Context */
#include "fee_cfg.h"
#include "nvm.h"

#define Fee_None 0x00U /* Take no action on single bit errors, (respond with corrected data), */
/* return error for uncorrectable error reads (multi bit errors for ECC or parity failures). */
/* For devices with no ECC (they may have parity or not) the only valid option is none. */
#define Fee_Fix 0x01U /* single bit "zero" error will be fixed by reprogramming, single bit "one" error */
/* will be fixed by marking the current entry as invalid and copying the data to a new entry,*/
/* return error for uncorrectable error reads (multi bit errors for ECC or parity failures). */

Is TI_FEE_DRIVER supposed to be 0 or none-0?  If non-zero, then where is it set?  If 0, then where is fee_cfg.h supposed to come from?

Thanks.

  • Hi,

    This issue was addressed in below thread 

    LAUNCHXL2-570LC43: Absense of Driver Header File - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    Please go through it and let me know if you have any further clarifications required.

    --

    Thanks,
    Jagadish.

  • Hi,

    When  I added the following to ti_fee_cfg.h:


    #define TI_FEE_DRIVER 1U

    the build report now says the following parameters are missing.  Please help me identify what I should set for these defines, which I assume will be added in ti_fee_cfg.h.  Thank you very much.

    >> Compilation failure
    source/subdir_rules.mk:9: recipe for target 'source/example_TI_Fee_Write_Read.obj' failed
    "C:/Users/plu/Documents/TMS_XL2-570LC43-Examples/TMS570LC43_FEE/include/ti_fee.h", line 330: error: identifier "TI_FEE_VIRTUAL_SECTOR_OVERHEAD" is undefined
    "C:/Users/plu/Documents/TMS_XL2-570LC43-Examples/TMS570LC43_FEE/include/ti_fee.h", line 333: error: identifier "TI_FEE_NUMBER_OF_VIRTUAL_SECTORS" is undefined
    "C:/Users/plu/Documents/TMS_XL2-570LC43-Examples/TMS570LC43_FEE/include/ti_fee.h", line 338: error: identifier "TI_FEE_TOTAL_BLOCKS_DATASETS" is undefined
    "C:/Users/plu/Documents/TMS_XL2-570LC43-Examples/TMS570LC43_FEE/include/ti_fee.h", line 339: error: identifier "TI_FEE_BLOCK_OVERHEAD" is undefined
    "C:/Users/plu/Documents/TMS_XL2-570LC43-Examples/TMS570LC43_FEE/include/ti_fee.h", line 390: error: identifier "TI_FEE_NUMBER_OF_BLOCKS" is undefined
    "C:/Users/plu/Documents/TMS_XL2-570LC43-Examples/TMS570LC43_FEE/include/ti_fee.h", line 400: error: identifier "TI_FEE_NUMBER_OF_EEPS" is undefined
    6 errors detected in the compilation of "../source/example_TI_Fee_Write_Read.c".
    gmake: *** [source/example_TI_Fee_Write_Read.obj] Error 1

    **** Build Finished ****

  • Hi,

    Sorry for the delay in my response.

    These errors are due to not generating basic code from HALCoGen, 

    If you generate the code from HALCoGen then this directives will be defined in the below file 

    I created a example code for you, so please download this and try it on your end, It got build successfully at my end.
    Please don't forget to download and install F021 flash library from below path before build the attached project.

    HERCULES-F021FLASHAPI Driver or library | TI.com

    TMS570LC_FEE.zip

    --

    Thanks,

    Jagadish.

  • Sorry, I missed your reply, perhaps because my email notification wasn't working some week(s) ago.  I was also tied up on other sub-projects.

    I'll look at this as soon as I get the chance.  I do need to get FEE working.

    Thank you very much.

  • Hi Peter Lu,

    Okay, do try and let me know if you are facing any issues.

    --

    Thanks,

    Jagadish.

  • Hi,

    I did give your project a try, and for some odd reason, it runs "fine" if I set breakpoints in parts of the code and run the code in sections, but if I run it in its entirety (with breakpoint on the last while(1)), the run never reaches the end.  I'm guessing that the various sections polling for operation completion are doing it too tight (despite the delays) that somehow the hardware doesn't set the right status, or perhaps data caching is causing the software not to read correct (volatile) status.

    Could you verify that the project will run to completion in your set-up?  It may be that my hardware is bad/different.

    I did not check to see if every stage of the project was doing the "right" things when things ran "fine" in sections, but just having a FEE project that builds and runs is great progress.

    Thank you very much;

  • On my hardware set-up, adding a delay() after the "while (Status != IDLE)" ensured the following TI_FEE_xxx() operation runs properly.  I guess the hardware needs some time before being able to perform the next operation.

    Please let me know if this is also the case on your hardware.  Thank you.

    	do
    	{
    		TI_Fee_MainFunction();
    		delay();
    		Status=TI_Fee_GetStatus(0);
    	}
    	while(Status!=IDLE);
    	delay();
    	

  • I modified the code a little, to add necessary delays and print data.  Unfortunately, I'm not seeing the (supposedly) written data read back.  It seems nothing is being read.  I modified block 1 in the .hcg fille to size 4096 (it was size 8, which would be too small to hold 100 bytes).  Note that read location 15 was purposely set to 0xff to show that correct locations are displayed.

    Can you double-check to see if your Read_Ptr area is indeed reading back what was supposedly written?

    Thank you very much.

    === Program output

    Starting program
    Reading...
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00
    Ending program

    void main(void)
    {
    /* USER CODE BEGIN (3) */
    
        unsigned int BlockNumber;
        unsigned int BlockOffset, Length;
        unsigned char *Read_Ptr=read_data;
        Read_Ptr[15] = 0xff; // just a display marker
    
        unsigned int loop, i;
    
        sciInit();
        printf("Starting program\n");
    
        /* Initialize RAM array.*/
        for(loop=0;loop<sizeof(SpecialRamBlock)/sizeof(SpecialRamBlock[0]);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);
        delay();
    
        /* 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);
        delay();
    
        /* 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);
        delay();
    
        printf("Reading...\n");
        for (i = 0; i < DATASZ; i++) {
            printf("%02x ", Read_Ptr[i]);
            if ((i % 16) == 15)
                printf("\n");
        }
        printf("\n");
        
        /* Invalidate a written block  */
        TI_Fee_InvalidateBlock(BlockNumber);
        do {
            TI_Fee_MainFunction();
            delay();
            Status=TI_Fee_GetStatus(0);
        }
        while(Status!=IDLE);
        for (i = 0; i < 3; i++)
            delay();
    
        /* Format bank 7 */
        TI_Fee_Format(0xA5A5A5A5U);
        do {
            TI_Fee_MainFunction();
            delay();
            Status=TI_Fee_GetStatus(0);
        }
        while(Status!=IDLE);
        delay();
    
        printf("Ending program\n");
    
        while(1);
    
    /* USER CODE END */
    }
    

  • Hi Peter,

    You are right about delay adding, and regarding data storage earlier we declared number of blocks as 1 and its size as 8 bytes right so only 8 bytes are storing in EEPROM, so just increase the block size and check.

    I increased to 256 and i checked and it worked fine for me.

    --

    Thanks,

    Jagadish.

  • Hi,

    Thanks for the confirmation, which gave me hope that things can/should work.

    My project kept on doing really oddball things, never running reliably or consistently.  But, once in a while, I did see the read data appearing in the debugger.

    After looking at the code more, I found the bug with the program.  The line...

       unsigned char read_data[100]={0};

    needs to be changed to something like...

       #define MAXBLKSZ 4096 // needs to be at least block size set in Halcogen

       unsigned char read_data[MAXBLKSZ]={0};

    I don't know why you didn't see run failures, but my project was over-running the read_data[] array on FEE read, and nasty things happened.

    The project runs fine now, in CCS 11 and CCS12.

    Thank you very much.

  • Hi,

    I rearranged the code so that I could verify that the "EE Prom" is actually being written as non-volatile storage and am not seeing the expected behavior.  I'm essentially doing:

    fee_init();
    if (dowrite) fee_write_async();
    fee_read();
    fee_show_read();

    The dowrite variable is entered dynamically by the user so that in any run of the project, the FEE write can be performed or not.

    One would expect that if the FEE were working properly, if on run #1, one does the write and on run #2 one skips the write, the fee_show_read() would display the same read data.  There is no re-flashing of the project between runs #1 and #2, so the FEE contents should be intact.

    The write and read in run #1 works fine, but that's not sufficient to show that data was actually written to some non-volatile memory.

    I'm not seeing run #2 (which skips the write) reading back the data that was written in run #1.  I'm re-running the project from the debugger using Run->reset, so no project re-flashing takes place between the runs.

    Please try this experiment and help me demonstrate that there is indeed a non-volatile FEE in operation.

    Thank you very much.

  • An easy way to set dowrite is:

    sciInit();

    ....

    sciSend(sciREG1, 15, "Dowrite (y/n): ");

    char yesno[1];

    sciReceive(sciREG1, 1, yesno);

    int dowrite = 0;

    if (yesno[0] == 'y') dowrite = 1;

  • Never mind.  Looks like the FEE non-volatile behavior works fine, even when the program has been re-flashed (between runs #1 and #2).  Don't know why it wasn't behaving this way before,  but after some machine (PC and Launchpad) reboots, etc, the FEE region is acting like a non-volatile memory.

    Thank you very much.

  • Hi Peter,

    Good to hear that, If all good then we can close this thread.

    --

    Thanks,

    Jagadish.