• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 2792 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.

FLASH programming in FreeRTOS

Evgenyy
Intellectual 490 points


Hello, everybody.

I have some question about FLASH programming on TMS570, when I also using FreeRTOS.

In the doc "Programming TMS570 Flash Using Flash API" (spna117a) I found that: "TI also recommends that you disable all the interrupts and exceptions during these operations because the Flash API might miss counting compact/erase pulses if the CPU is serving interrupt."

Is it enough to place portDISABLE_INTERRUPTS() and portENABLE_INTERRUPTS() OS functions, when I'm writing to and reading from FLASH using API functions Flash_Prog_B, Flash_Erase_B, Flash_Compact_B, or it is necessary to use portENTER_CRITICAL() and portEXIT_CRITICAL() OS functions?

Flash_Verify_B API function works perfectly without disabling interrupts, as I checked.

In advance thanks, Evgenyy.

  • 0
    TI__Genius 13810 points

    Evgenyy,

    1. The verify function read the flash contents with margin 0 and margin 1 mode. It can run with interrupt since it is not countering pulse. However, I missed one thing when I wrote the application note: When the margin 0/1 mode is enabled, the code you are runing now (flash API) is also in margin 0/1 mode if run from flash. Therefore, if it is a weak 0 or weak 1, the margin mode might read it wrong, generating a ECC error. So, to be safe, the verify function should be run from RAM.

    2. The flash API uses poll mode to count the erase/program pulses, the priority is lower than any interrupts and exceptions. If the ISR takes a long time to run, the API misses counting the pulses and makes some wrong decision.  That's why we should avoid that. As you know, the FIQ(NMI) can not be disabled once it is enabled. And you can only disable IRQ functions. I am not familar with these RTOS functions. So, I only show you the background behind this. Even if all the interrupt are enabled, as long as they are not served during the erasing/programming  time, it is OK.

    3. Here, I am talking about 'possibilities'. In both 1 and 2, the possibility to have a problem is low, but we want to avoid any problem that might occur during programming flash API.

    Regards,

    Haixiao

  • 0 in reply to Haixiao Weng
    Intellectual 490 points

    Thanks, Haixiao.

    Everything is clear.

  • 0 in reply to Evgenyy
    Prodigy 145 points

    I would like to make a suggestion to the designers of the Flash API.

    For those API functions that require disabling of interrupts to operate properly, don't expect the user of the API routine to disable interrupts.

    Preserve the interrupt state at the beginning of the API call, then disable interrupts within the API call for the critical sections of code.

    Restore the interrupt state upon return from the API call.

     

  • 0 in reply to Andrew Levi
    Intellectual 490 points

    Andrew, do you mean to make current interrupt pending, when calling FLASH API functions (also disabling interrupts inside them), and return to interrupt handler after finishing read/write flash memory?

  • 0 in reply to Evgenyy
    Prodigy 145 points

    Evgenyy,

    No, this has nothing to do with what is done outside of the FLASH API call other than removing the requirement to have interrupts disabled when making a FLASH API call.

    If the disabling of interrupts were done within the FLASH API call, this would be a much more efficient and safer way to implement the FLASH API as interrupts would only be disabled when absolutely necessary.

    Andy