• State TI Thinks Resolved
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 15 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0G1518: Function DL_FlashCTL_executeClearStatus() not placed in RAM

Pavlo Soltys
Prodigy 20 points

Part Number: MSPM0G1518

Greetings,

recently when reviewing the implementation of our flash write/erase functionality for MSPM0, we found that DL API function DL_FlashCTL_executeClearStatus() performs the clear status command via flashctl->GEN.CMDEXEC but is not placed in device SRAM(like DL_FlashCTL_executeCommandFromRAM()), and this excerpt from the MSPM0 reference manual(6.3.1 Overview of Flash Controller Commands) suggests that setting CMDEXEC and waiting for its result is not supposed to be executed from the flash bank being operated on:

"The software sequence of setting the CMDEXEC bit and waiting for the CMDDONE response must be executed from either the device SRAM or from a different flash bank from the bank that is being operated on, as the flash controller will take control of the flash bank undergoing the operation. Reads to the flash bank that is being operated on while the flash controller is executing the command are not predictable."

We would like to ask whether using DL_FlashCTL_executeClearStatus() to clear flash status is correct if the function code is located in the same flash bank on which operation is performed.

P.S. Also we had a look at the flash write examples provided with MSPM0 SDK(flashctl_program_with_ecc to be exact), and those just use  DL_FlashCTL_executeClearStatus() and seem to write to the same bank where program code is stored. Latest SDK was used(v2.11.00.07)

 

Best regards,

Pavlo

  • 0
    TI__Expert 7835 points

    Hi Pavlo,

    Yes, using DL_FlashCTL_executeClearStatus() while the function is located in the same flash bank is valid.

    The SRAM execution requirement applies to commands that actively program, erase, or otherwise operate on a flash bank. During those operations, reads from the affected bank are not reliable, so the command sequence must run from SRAM or from the other flash bank.

    DL_FlashCTL_executeClearStatus() is different. It only clears the FlashCTL command status and restores the protection state; it does not program or erase the flash array and does not take the bank out of read mode. For this reason, the function does not need to be placed in SRAM, and the usage shown in the SDK flashctl_program_with_ecc example is correct.

    The actual program or erase operation must still use the RAM-based DriverLib API, or execute from the alternate flash bank. Also ensure no interrupts or code fetches occur from the bank being modified during that operation. Hope this helps!

    -Brian

  • 0 in reply to Brian Dempsey
    Prodigy 20 points

    Thank you for the response Brian, it helps. 

    Using the occasion we would also like to get a clarification regarding interrupt disabling during operating on flash.

    Our current write/erase routine looks as follows:

    DL_FlashCTL_executeClearStatus(FLASHCTL);   // Legal to execute from flash
    DL_FlashCTL_unprotectSector(FLASHCTL, address, DL_FLASHCTL_REGION_SELECT_MAIN);  // Allow modification
    IRQ_DisableAll();  // globally disable interrupts to not fetch instructions from flash if interrupt happens during modification
    // Program / erase memory here from RAM
    IRQ_EnableAll();
    We already have a locking mechanism in place to serialize flash operations so that multiple writers don't race on flash controller access. Given that, could any issue potentially occur if DL_FlashCTL_executeClearStatus() or DL_FlashCTL_unprotectSector() get interrupted or delayed by a sudden interrupt load?
    Thanks in advance.