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.

CCS/TMS570LS0714: F021 library for use with TMS570LS0714

Part Number: TMS570LS0714
Other Parts Discussed in Thread: TMS570LS1224,

Tool/software: Code Composer Studio

Greetings;

We have a current development project using the TMS570LS1224 with some F021 flash aspects, that has been working very well for a few years with no issues.

We are recently porting sections of our project to a new project using the TMS570LS0714 and are having issues with the F021 API causing errors.

First question, which F021 library should we be using for the 714?  We had been using F021_API_CortexR4_BE_V3D16.lib for the 1224 and reading through the documentation for the F021 (SPNU501G.pdf) there doesn't appear to be a concern about this library with the 714.  Should we be using a different F021 library?

From there, the issue is when we do writes or erases using F021 API we receive 0x30000 (status = 48) in FMSTAT which implies that the memory location has 0s even though it passes erase check.

But I want to make sure that I am not missing something easy or obvious because of the different part in the same family.

Thanks in advance,

Joe

  • Hello Joe,

    1. TMS570LS0714 and TMS570LS1224 use the same F021 API library: F021_API_CortexR4_BE_V3D16.lib

    2. TMS570LS0714 flash has only 11 sectors, but the flash on LS1224 has 15 sectors. 

  • QJ;

    Thank you for the response.

    The issue we appear to be having is that when we call the Fapi_issueProgrammingCommand() API command, the result is 48 (0x3000) which is FMSTAT.INVDAT, invalid data.

    INVDAT states: "When set, this bit indicates that the user attempted to program a 1 where a 0 was already present."  However, before issuing this command we do a blank check which shows that the area which we wish to program is all 1.

    Furthermore, if we step through the code during debugging using CCS, this Fapi_issueProgrammingCommand() succeeds on the 714.

    Also, as stated earlier, this code has been working perfectly on the 1224 (with or without debug mode) for years.

    Here a sanitized version of the code in question.

    // for this operation, dst = 0x10000
    
    Flash_Erase_Check(dst, 0x10);  // start address, length, checks for 0xFF in each byte
    
    Fapi_initializeFlashBanks(SYS_CLK_FREQ); 
    
    Fapi_setActiveFlashBank((Fapi_FlashBankType)0);
    
    Fapi_enableMainBankSectors(0xFFFF);
    
    Fapi_issueProgrammingCommand((uint32_t *)dst, (uint8_t *)buffer, (uint32_t)size, 0, 0, Fapi_AutoEccGeneration);
    
    // at this point we read the FAPI status and get 48 on the 714

    Any additional insight you might have on the issue would be appreciated.

    Thanks in advance,
    Joe Shidle

  • Joe,

    Since LS0714 has only 1 flash bank, you need to run the flash AI library from SRAM instead of flash. Did you copy the code to SRAM and execute the code from SRAM?

  • QJ;

    Thanks again for your response.

    The code in question is the SafetyMCU_Bootloader code from TI and it appears that in the sys_startup.c function _c_int00() there is a call to _copyAPI2RAM_() which, in sys_core.asm appears to "copy the Flash API from flash to SRAM"

    So yes, it appears that we are copying and executing the FAPI code from SRAM.

    Is there anything else?

    Thanks in advance,
    Joe Shidle

  • Hello Joe,

    When you initialize the flash bank, did you check if the bank is initialized successfully?

    if ((Fapi_initializeFlashBanks((uint32_t)SYS_CLK_FREQ)) == Fapi_Status_Success){

           (void)Fapi_setActiveFlashBank((Fapi_FlashBankType)0);
           (void)Fapi_enableMainBankSectors(0xFFFF); 
    }else {
           return (1);
    }

    What happens if you erase the sector again using F021 flash API before programming data?

  • Hello QJ;

    Thank you for the response.

    QJ Wang said:

    When you initialize the flash bank, did you check if the bank is initialized successfully?

    We do not, as we copy code from TI examples in the original F021 API software bundle and they do not check return values there. 

    When I add code to check the return value of the Fapi_initializeFlashBanks(), I receive return value of 8 which per the reference manual is FMSTAT.VOLTSTAT which is a core voltage status.

    However please note two things:

    1) I receive this same FMSTAT.VOLTSTAT when I am running the same code through the debugger, and the later flash program succeeds.

    2) I added check of the return value for the Fapi_setActiveFlashBank() and Fapi_enableMainBankSectors() and both return status = 0 which is success, for both cases of running in debugger when flash write succeeds and running on processor when flash write fails.

    So I am skeptical that the VOLTSTAT is a concern, but I am open to suggestions.

    QJ Wang said:

    What happens if you erase the sector again using F021 flash API before programming data?

    When I erase the sector prior to programming the data:

    1) Everything is successful (erase, program) when I run through the debugger.

    2) The chip resets during the erase sector, when I run it normally on the device.

    Thanks in advance for your further help,

    Joe Shidle

  • Does anyone else have any thoughts on this issue?  This is still a problem for us.

    Thanks in advance,

    Joe Shidle

  • Hello Joe,

    "VOLTSTAT" being set usually implies that the pump supply (VCCP) dropped below the minimum threshold defined in the datasheet. You can capture the VCCP waveform during program/erase operations to see if it is indeed dipping below 3.0V. Do you have a cap on the VCCP pin very close to the micro?

  • QJ;

    Thank you for the response.

    We have a 1uF capacitor extremely close to the VCCP pin.  In the words of the layout engineer it is "as close to Pin 134 as it can possibly be."

    I'm not in a position to measure the voltage on this pin today, but I should be able to perform this by tomorrow.

    In the meantime, I would like to repeat what I'd said earlier:


    1) We are able to use the debugger to step through the code

    2) When we step through the code in this manner, the flash write operation is successful

    3) When we step through the code in this manner, we also see the VOLTSTAT bit triggered

    So either the VOLTSTAT is not the cause of the flash write failure when we are not using the debugger, or there is something baked into the debugging process that prevents the VOLTSTAT from interrupting the flash write process.

    I will observe the VCCP pin and get back to you.

    Thanks for your response and attention,

    Joe Shidle

  • QJ Wang said:

    You can capture the VCCP waveform during program/erase operations to see if it is indeed dipping below 3.0V. Do you have a cap on the VCCP pin very close to the micro?

    QJ;

    I was able to find time to measure the voltage at the VCCP pin.  At no point during the flash operation does the VCCP voltage dip below 3.0V.  In fact, it maintains a very very stable 3.3V throughout the process.

    The VCCP is very stable 3.3V whether I am stepping through the code (flash write successful) or running standalone (flash write fails).

    Let me know what further thoughts you have.

    Thanks in advance,

    Joe Shidle