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.

TMS320F28375S: F021 Flash API Erase problem

Part Number: TMS320F28375S

Dear C2000 experts,

We are facing a strange problem using F021 Flash API. The device is F28375s.

We are trying to erase and then program some sectors of the flash bank 1. Most of the time (about 3 out of 4), the procedure completes successfully.
In the remaining cases, apparently in a completely random way, the CPU stops during the check "Fapi_checkFsmForReady() != Fapi_Status_FsmReady".
Sometimes it also stops in random locations, for example in the secure ROM addresses.

Also, it seems the problem appears only during the erase phase. The programming works ok.

The steps we make for the erase are the following:
- Check if the bank we want to erase has been activated
- If not, we claim the PUMP semaphore, call Fapi_initializeAPI and then Fapi_setActiveFlashBank
- call Fapi_issueAsyncCommandWithAddress
- wait until the command complete by checking "Fapi_checkFsmForReady() != Fapi_Status_FsmReady" (This seems the problematic step)
- read the erase result by calling Fapi_getFsmStatus

Here what we have checked so far:
- All the used function are loaded in RAM, also the wrapping functions
- After copying the functions on RAM and before calling the erase function, we check if the RAM has been corrupted in some way
- We don't use the restricted memory areas as per the errata advisory "Memory: Prefetching Beyond Valid Memory"

Have you any suggestions?

Please let me know if you need some further information.

  • Hi Alberto,

    Did you program passwords or any other settings in DCSM space?

    Did you execute the flash initialization routine for the second bank as well in your application?  Please check and add if not already.

    When you say the CPU stops, does debugger halt there?  Or when you halt it, you see the PC stuck there?

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    No, we don't use any password or other features of the DCSM space.

    Yes, we execute the initialization routine of the second bank as well. In our application Bank 0 is initialized by default, then we initialize the second bank. Essentially, in our routine, we disable the ECC for both Bank and then initialize Bank 1. We also added an extra wait state just in case, although the datasheet states it should be added automatically. I have attached a screenshot.

    Yes, when I say the CPU stops, I mean the debugger halt. Sometimes it halt on "Fapi_checkFsmForReady() != Fapi_Status_FsmReady", other times somewhere in the secure ROM or sometimes in the reset vector. Another strange behavior is that, once the debugger halts, if we have variables on the watch list, they seem to change randomically. On the other hand, all the internal registers appear to be ok and do not change.

    Thanks, 

    Alberto

  • Alberto,

    Thank you for the details.

    Please remove that extra wait-state.

    Hope you checked and there is no any previous breakpoint in those areas.

    Can you share your linker cmd file and map file once?

    Thanks and regards,

    Vamsi

  • Alberto,

    Few more things to check:

    Do you have an debugger memory window open to flash or OTP when checking this? If yes, please close and try.

    Which emulator are you using?  Please check and install any updates available for the emulator.

    Is this happening on multiple devices or a single unit?

    Thanks and regards,
    Vamsi

  • Dear Vamsi,

    we performed a quick test without the emulator attached and it seems it is working correctly. We will perform some further extensive tests, and let you know the result.

    Thanks,

    Alberto

  • Alberto,

    Thank you for the update.  It might be due to some stale breakpoints.  

    I will keep this thread in pause until you come back with your results.

    Thanks and regards,
    Vamsi

  • Alberto,

    Do you have any update on this?  Can I close this post?

    Thanks and regards,

    Vamsi

  • Hi Vamsi,

    we confirm that without the emulator attached it seems to work properly.

    The issue can be considered closed.

    Thanks for your support.

    Alberto