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.

TMS570LS0432: FEE Driver cannot handle Active Bank / FMAC not set to Bank 7 before calling its FEE Write API.

Part Number: TMS570LS0432
Other Parts Discussed in Thread: HALCOGEN

Hi TI FEE team,

If data were being written to both Regular Flash Bank 0 and FEE Flash Bank 7 back to back, the FEE API's TI_Fee_WriteAsync() cannot handle the write because FMAC was no longer set to Bank 7. Is the FEE Driver expecting its caller to set FMAC back to Bank 7? Other than FMAC, were there other flash registers that can't be modified after TI_Fee_Init()?

And if FMAC was set to Bank 0 when TI_Fee_WriteAsync() was called, the FEE's Job Result returned JOB_OK even though the flash write action did not go through. Is it possible that there are other code path in FEE Driver not setting the correct Job Result?

FEE Driver version 1.19.04 is what being used.

Thanks!

-Kevin.

  • Hi Kevin,

    If FEE is used in an application and if another bank is made active after FEE driver initialization, then the application need to set the FEE bank to Active after completing operations on Bank 0/1. Fee Init API also enables SECDED and enables reading all 1's OK.

    TI_Fee_WriteAsync() assumes FEE bank to be active and that's the reason it returns JOB_OK. The way we verify a successful write is to read back the data using Fee_read API.
  • Hi Vishwanath,

    Is FEE bank be active the only assumption of the current FEE driver? Can you please provide a list of other assumptions if there are any?

    As for the Write operation, instead of depending on the Job Result, is it the recommendation is to do a read back on all FEE write operation?

    Thanks,
    -Kevin.
  • Hi Kevin,

    FEE driver does following settings too:
    -Enables SECDED
    -Enables reading of all 1's OK.
    -Sets Active bank to 7.
    -Enable all EEPROM sectors.

    Yes, please use read api to verify successful write.
  • Hi Vishwanath,

    Is this an acceptable solution? In ti_fee_util.c, function TI_FeeInternal_WriteDataF021(), I added the code the set the active bank:

                    Fee_WriteAddress = TI_Fee_GlobalVariables[u8EEPIndex].Fee_oWriteAddress;                                                
                    /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Reason -  Fee_pu8Data is assigned a value and it can't be NULL."*/
                    /*SAFETYMCUSW 440 S MR:11.3 <APPROVED> "Reason -  Casting is required here.*/
                    if(NULL_PTR != TI_Fee_GlobalVariables[u8EEPIndex].Fee_pu8Data)
                    {
                            pu8Data = TI_Fee_GlobalVariables[u8EEPIndex].Fee_pu8Data;
                            TI_Fee_GlobalVariables[u8EEPIndex].Fee_pu8Data += u8ActualWriteSize;
                    }                       
                    TI_Fee_GlobalVariables[u8EEPIndex].Fee_oWriteAddress += u8ActualWriteSize;
            }               
    +
    +       /* Set Active Flash Bank and Sector for FEE */
    +       (void)Fapi_setActiveFlashBank(Device_FlashDevice.Device_BankInfo[FEE_BANK].Device_Core);
    +       (void)Fapi_enableEepromBankSectors(FEE_ENABLE_SECTORS_31_00, FEE_ENABLE_SECTORS_63_32);
    +
            /*SAFETYMCUSW 114 S MR:12.6,13.2 <APPROVED> "Reason -  Eventhough expression is not boolean, 
              we check for the function return value."*/
            /*SAFETYMCUSW 184 S LDRA adding spaces causes this rule to fail."*/     
            /*SAFETYMCUSW 114 S MR:12.6,13.2 <APPROVED> "Reason -  LDRA does not understand macro 
           FAPI_CHECK_FSM_READY_BUSY."*/
            /*SAFETYMCUSW 440 S MR:11.3 <APPROVED> "Reason -  ( pFapi_FmcRegistersType ) ( 0xFFF87000U ) ) casting 
              is done in F021 library.*/
            if(FAPI_CHECK_FSM_READY_BUSY == Fapi_Status_FsmReady)
            {               
                    /*SAFETYMCUSW 184 S LDRA adding spaces causes this rule to fail."*/
    Do you see any corner case that did not covered? Is there any benefit from calling TI_FeeInternal_EnableRequiredFlashSector() vs Fapi_enableEepromBankSectors()?
    Thanks,
    -Kevin.
  • Hi Kevin,

    I do not recommend to do it here since TI_FeeInternal_WriteDataF021() would be called periodically during write/copy operations. I would rather do it where Bank0/1 was set to active and after completing required operations on it, set Bank 7 to Active and enable all EEPROM sectors. You need not use  TI_FeeInternal_EnableRequiredFlashSector().

  • Hi Vishwanath,

    According to F021 Recommended Program Flow, the bank and sector should be set before issuing the flash command. What is your concern on TI_FeeInternal_WriteDataF021() being called periodically since what I proposed is following the suggested flash sequence of F021.

    I am looking for a fix that can be contained within the FEE driver since application should be free to use any non FEE sectors. Do you have another suggestion that can be directly applied to FEE driver alone?

    If restoring FEE bank/sectors is a must, can you provide an updated FEE User Guide that has this requirement documented?

    Thanks,
    -Kevin.
  • Hi Kevin,

    If it has to be contained inside FEE driver, then your implementation is correct. My concern was the piece of code gets repeated for every write. You may do a small experiment to write "x" number of bytes without the fix and with fix and see if there is a in change is write execution times. If your application can absorb the additional execution time, then the change is ok.

    I have raised an internal ticket and will update the user guide to document this. Updated user guide will be provided in next HALCoGen release.