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.

FEE module on TMS570 never properly initializes, keeps returning UNINIT

Other Parts Discussed in Thread: HALCOGEN, TMS570LC4357, TMS570LS3137

  In working with the FEE module I eventually found the example FEE example application that is included with the HALCOGEN stuff.  I followed the directions at the top of the file in order to get it running and have been able to get it to compile and run but the FEE module never gets properly initialized and as a result hangs at the top of the program where it checks for initialization prior to proceeding.  The module never seems to make it out of UNINIT status.  I have been unable to trace down where I went wrong but it seems like something isn't configured right.  I have included the CCS project that I am using for this test application.  The F021 libraries, files, and HALCoGen files are all located in the HALCOGEN folder in the project.  

I am using a TMS570LC43x development kit for my project and HALCoGen v. 4.04.00, and CCS  6.1.0.00104.  

1638.FEE_EXAMPLE_CODE.zip

  • Hello:

    We have received your post and will direct it to the FEE driver expert to get some feedback.

    Regards.
  • Hello Chris,

    I have created a new project using HALCogen 04.04.00 and I did not find any issues with FEE. I'm attachig my project.

    If you still find issues during Initialization, please check value in TI_Fee_GlobalVariables.Fee_Error and let us know.

    2476.Fee_problem.zip

     

  • Thank you for the example project and it definitely helps.  It looks like the reason that I was unable to initialize the FEE module correctly is because I was using the wrong version of the F021_API_CortexR4.lib.   The one you included was actually the one I initially felt was appropriate but after reading through the instructions for the FEE Example I decided on the non "L2FMC" version based on what it said.  This isn't very clear in the directions as part of the FEE example and maybe could use some additional clarification in the comments/instructions.  The project now runs through the initialization but I do not get the read back that I would expect.  after the TI_Fee_Read() call read_data is still full of '0' values.  I have loked at oResult and it reports "OK" along with the TI_Fee_GlobalVariables ->Fee_Error which reports Error_Nil.  Attached is a screen shot of my breakpoints and variable views.  I get the same output with break points at line 181 or line 191.  This is the same project that you sent me with only one modification.  I had to set my emulator to the XDS100v2 that is built into the development kit I used since I don't have an XDS510.

    Thanks,

    Chris

  • The discussion in the following forum thread may be helpful to you.

    e2e.ti.com/.../418566

    Thanks and regards,

    Zhaohong
  • I am not sure how that other thread is supposed to help me. The discussion is focused on the boot loading functionality and the ability to execute out of RAM and FLASH memory. If I am missing about how this is applicable let me know what I am missing.

    In your first post you mentioned that the program you sent me initially "ran without issue". Did you actually confirm on a TMS570LC43x dev kit that the FEE memory space got set, and then was able to be read back into the read_data array? If so, I don't get why it doesn't happen on my dev kit.

    As I have dug into this more, according to the TMS570LC4357 the memory space for the EEPROM emulation is located at: 0xF020_0000 (EEPROM_BANK). When I attempt to look at this memory space in the "Memory Browser" in CCS it always reports 0xFFFF FFFF for all cells. As a result it seems to me like the write is not going through to the memory. Is this the proper method to view this sort of information? Is there something else I can use in CCS that would aid in knowing if the memory is at least written correctly even if the writes seem to be failing?
  • Take a look at the last post of the thread. There is an example of using FEE lib on TMS57LC4357.

    Thanks and regards,

    Zhaohong
  • Thanks for the clarification on that. Unfortunately, when I pull that project down and run it I get the same results from the previous FEE project you included for me. Additionally, the thread never mentions if the person you were working with ever attempted to run the FEE project or if it ran successfully. At this point it seems like I am still at the same point that although my code seems to run and all indications from the FEE functions are nominal, nothing seems to be read back out of memory correctly. Also inspection from the memory browser seems to indicate that memory is not being set.

    --Chris
  • Hi Chris,

    This is something to do with cache. For time being, you can comment out _cacheEnable_() in HL_sys_startup.c file. We will provide you further information on how to overcome this problem.

  •    Looks like that has gotten the example program up and running.  Please let me know once you get the details on how to re-enable the cache because I really need this enabled for my application in order to get the speed advantages I want to utilized in my application.  

    Thanks for the support and look forward to hearing more back on the cache issue.

    --Chris

  • Did you guys ever find out more about how to run this with Cache enabled? I have been able to successfully integrate the FEE module into my main program but without the cache enabled it runs to slowly. I only need to load & save to the FEE at the beginning of my program so I can re-enable cache after this operation is completed. The problem is that when I attempted this it would "Zero Out" the memory that the FEE previously successfully wrote to. What would be the best way to re-enable the cache? Or solving the root problem of this?

    When I attempt to re-enable the Cache after loading from the FEE my code looks like: 

    if (doOnce)
    {
    _cacheEnable_();
    _dCacheInvalidate_();
    _iCacheInvalidate_();
    doOnce=0;
    }

    if I set a break point at the "If" statement my variable array "TargetGAPCntrl" has the expected data within it.  Looking at the memory browser it looks like:

     

    Then if I allow it to run to the line 309, after the cache enable the process of enabling the cache has zeroed out a good portion of my memory space for the vairable TargetGAPCntrl array.

    this is really confusing considering the memory space that this variable is at (and memory browser) is within the RAM memory space.  I don't get why once I have the data loaded into RAM that enabling the cache is causing it to get zeroed out.  

  • Hi Chris,

    Before doing any read's from FEE bank, call _dCacheInvalidate(). This will invalidate datacache and read data from FEE bank.
  • I have attempted the following lines of code for the Read:

    _dCacheInvalidate_();
    retVal=TI_Fee_Read(1,0,(unsigned char *)calArr,sizeof(calArr));

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

    The problem I am having is that when running the code the FEEStatus that is returned is UNINIT. Also, retVal returns from the read as E_NOT_OK meaning the read was un-successeful. This only happens when I have the CacheInvalidate call in the code. As a result I am still stuck.

    Part of my struggle here is not knowing what the cause of this problem is? Do you know why I need to disable the cache to get the FEE module to work? What is the bug, HW issue, etc?

    Thanks,
  • Hi Chris,

    I have updated project MPU settings. I have verified this project and it worked. You can use this as base for your project.

    1256.Fee_problem1.7z

  • That version does appear to work. What parameters did you change in the configuration to get it to work? The only thing I could easily identify that was different than my build was that you were using the compiler version TI v5.1.9 [TI v5.1.12] as the compiler where the compiler I was using was TI v5.2.4. With that said, I tried 5.2.4 on the above project 1.7 and it still appears to work. So please fill me in on what you did to change the project settings in order to allow it to work.

    I also am still looking for an explanation as to what is actually going on and where things are getting tripped up. This is a supposed to be a processor targeted to safety critical applications. It doesn't make me feel real comfortable moving forward without at least understanding what the problem is, and how the "fix" addresses it so I know all the parts in the system and make sure I don't bump up against it again.

    --Chris
  • Hi Chris,

    Default MPU settings generated from HALCoGen were not correct. That's the reason the FEE example did not work. I have provided MPU settings from previous version of HALCoGen. We will change the default MPU settings in next release.
  • Hi,

    I've been trying out FEE on HDKs for TMS570LS3731 and TMS570LC4357. I am simply follwing the example instructions, using default setting for FEE in Halcogen and replacing the generated main-file with example_TI_Fee_Write_Read.c.

    TI_Fee_Init(), TI_Fee_WriteAsync(), TI_Fee_WriteSync(), return with follwing values in TI_Fee_GlobalVariables:

    I expect other values than 0xFF at address 00xF0200000 and following, however all cells are still filled with 0xFF.

    TI_Fee_Read() returns :

    Not sure why it returns BLOCK_INVALID. the example should work with default halcogen settings which are:

    The thread suggested to comment out _cacheEnable_() in HL_sys_startup.c.

    For the TMS570LS3731 generated file is called sys_startup.c and doesn't contain a line _cacheEnable_() . For the TMS570LC4357 Halcogen geneates HL_sys_startup.c and it does contain _cacheEnable_(). Uncommenting it doesn't change the behavior.

    I am linking wiht lib F021_API_CortexR4_BE_V3D16.lib.

    IDE is IAR 7.50.3

    Halcogen Version: 4.05.01

    Can anyone help?

  • Hi,

    You are using correct library for TMS570LS3137 device. For TMS570LC4357, you need to use a library having the name *_L2FMC*. 

    Can you attach your projects to this post?

  • Hi,

    In IAR, you need to make changes in CGT_IAR.h file as suggested in following thread.

    e2e.ti.com/.../1526765
  • Hi Vishwanath,

    that was really fast and it solved my problem. Thank you so much for helping.

    Regards,
    Juergen
  • Hi Vishwanath,

    I have to ask one more question, I am not sure what following lines in the example code do:

    /* 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);

    Weirdly they seeem to cause a funny behavior. If I uncomment them, everything works fine.

    If these lines are part of the code I observe following:
    # It works if I attach a debugger and add a breakpoint at line TI_Fee_InvalidateBlock(BlockNumber), stop there and continue.
    # no breakpoints or no debugger at all leads to a data abort exactly every 2nd time after reset or power up (ok, abort, ok, abort...)

    Do you have any hint what could go wrong?

    Regards,
    Juergen
  • Hi Juergen,

    You should have noticed this problem in TMS570LS4357 device but not on TMS570LS3137, right? We have observed this behaviour recently on Hercules devices containing FLEE type of FEE bank. These type of FEE banks take longer time to get programmed. If CPU tried to read when FEE banks are getting programmed, then depending on what CPU reads, it may cause undefined behaviour. This issue is already addressed and released in latest HALCoGen v04.05.02 released yesterday. Please update HALCogen and let us know if you still observe this behaviour.

  • Hi Vishwanath,

    correct, the problem only showed on TMS570LS4357. The Halcogen udpate fixed it. For my understanding, can you explain what these two lines do:

    TI_Fee_InvalidateBlock(BlockNumber);

    TI_Fee_Format(0xA5A5A5A5U);


    Regards,

    Juergen

  • Hi Juergen,

    TI_Fee_InvalidateBlock(BlockNumber) API will update the status of the block to Invalid. This means, if you write a block and then read it, you will get data from FEE. If you read the data after Invalidating the block, you will not get data from FEE.

    TI_Fee_Format API will format complete FEE bank. Application should be very careful in using this API. Formatting will erase all the data on FEE bank.