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.

TMS320F28377D: Flash init after CSM unlock

Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE, C2000WARE

Hi

I have found (empirically) that after unlocking the CSM at runtime I need to re-initialize the flash API (i.e. call Fapi_initializeAPI) to get further Flash API functions to work.  However, I do not see where this is documented.  I want to make sure this is actually required and not masking another configuration issue.  Thanks!

Paul

  • Paul,

    Did you call this function when the memory is secured and all the flash operations worked fine?  And later when you unlocked, the flash API did not work fine for the same flash sectors?

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    Thanks for the quick reply.   Sort of.  The function that I had an issue with is a setup function, so I haven't really accessed any sectors of flash for read/write yet.  The function I was having an issue with is Fapi_setActiveFlashBank.  That function is called twice.  The first time occurs right after calling Fapi_initializeAPI but prior to calling the function that unlocks the CSM.  Subsequently,  the CSM is unlocked and the second call to Fapi_setActiveFlashBank produces an issue. 

    The issues I'm seeing with the second call is that while it returns with status Fapi_Status_Success, I found that the part of the stack used by the function I called Fapi_setActiveFlashBank from had been modified.  Inserting the Fapi_initializeAPI function just prior to calling Fapi_setActiveFlashBank kept that part of the stack intact.

    To debug, I stepped through the assembly (with CSM unlocked) and found that the case where Fapi_initializeAPI is called first modifies values in the 0x50000 range, while the case without having first called Fapi_initializeAPI causes the same values to be changed, but offset from 0x0 instead of 0x50000. 

    I guess to summarize, this order does not work:

    Fapi_initializeAPI -> Fapi_setActiveFlashBank -> UnlockCSM -> Fapi_setActiveFlashBank

    The work around appears to be (note the added flash API init):

    Fapi_initializeAPI -> Fapi_setActiveFlashBank -> UnlockCSM -> Fapi_initializeAPI -> Fapi_setActiveFlashBank

    Is this the expected behavior?  Thanks!

    Paul

  • Paul,

    Thank you for the info.

    Could you clarify how the stack is modified?  Is it by executing the unlock procedure?  Or by executing the Fapi_setActiveFlashBank() for the second time?

    Do you issue a debug reset before or after CSM unlock?

    Thanks and regards,
    Vamsi

  • Hi Vamsi,

    Sorry for the delayed response.  I think I got to the bottom of the issue.  It occurs independent of the CSM lock/unlock.  The source of the issue is that we properly initialized the API via Fapi_intiializeAPI, but then re-relocated the code segment containing the Fapi functions, and did not re-initialize.  What I found is that the Fapi_setupFlashStateMachine routine (called from Fapi_setActiveFlashBank) looks at a fixed offset from where it is loaded in memory.  This values at the offset get initialized when Fapi_intiializeAPI is called.  So, re-locating the code section that had the Fapi routines, without again calling Fapi_intiializeAPI, left those memory locations at 0s.  Further writes occur relative to the addresses in memory at those locations, so were modifying our stack by mistake. 

    Is the source available for the Fapi functions?  I was unable to locate them in C2000ware or controlsuite.  That might lead to a little more insight here.  Thanks for your help!

    Paul 

  • Paul,

    Thank you for the update. Glad to know that the issue is fixed.  Yes, Fapi_initializeAPI() has to be called in that case.  

    Flash API source code is not provided in the C2000Ware.  It will be provided under NDA when there is a legitimate reason for application certification purpose.  

    Thanks and regards,

    Vamsi