• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 83 subscribers
  • Views 166 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28035-Q1: Disable the global interrupt before flash api

Shuqing Zhou
Intellectual 2695 points

Part Number: TMS320F28035-Q1

Tool/software:

Hi experts,

In our FLASH API doc, it says it can disable the interrupt before call the flash api

and in this chapter, it give the code demo how to do it

Since it is the assemble code, so customer use the asm() to realize it, could you help to check if it any wrong in below function?

BRs

Shuqing

  • 0
    TI__Guru* 83050 points

    Shuqing,

    I'd like to get a little more background on the customer use case.  When I read the Flash API guide, I believe "Step 9" is saying that it is option for the customer to disable global interrupts since the flash API will take care of this as needed so time critical code will not be impacted.

    So, the customer could choose to disable interrupts if they wish(using the standard DINT command and EINT when done), but it is not required.

    All of the functions the customer has mentioned, shouldn't need to be re-duplicated in their code base.

    Let me know if there is more detail on the end requirement the customer has here, and I will be happy to take a look.

    Best,

    Matthew

  • 0 in reply to MatthewPate
    TI__Guru* 83050 points

    Shuqing,

    Replying back based on our conversation, in order to disable global interrupts before calling flash API, customer can just use DINT in their C code(this macro will take care of disabling global interrupts by setting the INTM bit) and then use EINT when flash programming is complete

    The XNMI section is not applicable to F2803x/02x.  This was present in previous Gen2 devices, like F2833x, but was removed in F2802x/3x/6x devices; so there is no need to do any thing for XMNI by customer.  This address range is reserved in F2802x/3x; so even if API still has this call(which I doubt) the code doesn't do anything.

    Now, for the below concern:

    This is meant for those use cases where customers are still running time critical control code, and NOT disabling interrupts before entering the flash API.  In this case it is referring to when the API itself disables ISR during erase, there will be 3-4ms of time, potentially before an ISR could be serviced.

    In this case customer is only doing boot to FW update, so there is no time critical code, etc.

    The other thing I want to highlight to the customer is the erase time we list in the DS:

    https://www.ti.com/document-viewer/TMS320F28035-Q1/datasheet#GUID-3780BF1F-53A1-460D-98F3-F029AC4CE5BA/TITLE-SPRS523SPRS5237446

    The max erase time is 12 seconds/per sector, with a 2s/sector as TYP.  Customer needs to make sure that any external component, like Watchdog or something else that may be pinging the F2803x will not pull XRSn on the F2803x due to time.  This erase time hold off window is very important to observe in the system.

    If this is too long, we can explore re-enabling the interrupts and allowing the 3-4ms time durations of the API for servicing any external monitor, etc.

    Finally,

    As a rule of thumb to avoid CSM(Code Security Module Issues); if customer can avoid programming Sector A/H it will be best case if there is a power fault for not impacting the CSM and locking the device.  This may not be possible based on where the customer is in their development/release process.  But I did want to bring it up in case it is helpful for the FW update strategy.  There is no issue with A/H, but if flash program/erase is interrupted and these are active sectors, then it could cause CSM corruption, which will lock the device.  

    Based on our conversation, I am not sure that is the issue customer is seeing, rather something electrically wrong with the flash based on FA.  If locking is not being observed, then you can dis-regard the above paragraph.

    Best,
    Matthew