MSPM0G3507: MSPM0G3507 fail to erase flash sector when only last 64 bits are non 0xFF

Part Number: MSPM0G3507
Other Parts Discussed in Thread: MSP432E401Y, , UNIFLASH

We take the driver lib code as reference to make our own MCAL library.

And we have a function to erase a flash sector.

This funcion works well for all other conditions.

But there is one case I saw sector erase fail: 

Only the last 64 bits are valid data in this sector but all other data are 0xFFFFFFFF

The STATCMD register shows cmd pass and done, but data was not erased.

Then I tried to write some data at first 64 bits before erase it. It works.

But TRM did not mentioned this kind of operation needed when do sector erase.

Why sector erase failed in this condition? What should I do to prevent it?

 

 

Below is the reference code for us to erase the flash:

    /*! Erase the next sector*/
    FLASH_Unlock();
    
    /* Set command type and size */
    FLASHCTL->GEN.CMDTYPE = (FLASHCTL_CMDTYPE_SIZE_SECTOR | FLASHCTL_CMDTYPE_COMMAND_ERASE);
    
    /*! Select the target erase base address in the CMDADDR registers*/
    FLASHCTL->GEN.CMDADDR = pageAddress + FLASH_PHYSICAL_PAGE_SIZE;
    
    /*! Execute and wait for the response*/
    FLASHCTL->GEN.CMDEXEC = FLASHCTL_CMDEXEC_VAL_EXECUTE;
	status = FLASH_WaitForCmdDone(FLASHCTL);

    /*! Restore Configuration to noop command*/
    FLASHCTL->GEN.CMDTYPE = FLASHCTL_CMDTYPE_COMMAND_NOOP;

__STATIC_INLINE bool FLASH_WaitForCmdDone(FLASHCTL_Regs *flashctl)
{
    /* Wait for command to complete */
    while ((flashctl->GEN.STATCMD & FLASHCTL_STATCMD_CMDDONE_MASK) !=
           FLASHCTL_STATCMD_CMDDONE_STATDONE) {
        ;
    }

    return ((flashctl->GEN.STATCMD & FLASHCTL_STATCMD_CMDPASS_MASK) ==
            FLASHCTL_STATCMD_CMDPASS_STATPASS);
}


  • This fail is not 100% happened, the first time erase after flash by J-link will work. But second time erase have high potential to fail

  • Hello Yiren,

    I want to check some details with you

    • Can you explain what is the meaning of "the first time erase after flash by J-link will work. But second time erase have high potential to fail", could you provide more details about this?
    • If you change to another unit, will this issue also occur?
    • If you don't use J-Link, but use XDS110, will this issue also occur?

    BR,

    Janz Bai

  • This sounds suspiciously like MSP432E401Y Erratum MEM#15 [Ref MSP432E Errata (SLAZ709A) p. 8]. Different product line, but I've seen some hints that they share some IP.

  • Hello Janz,

    Thank you for looking into this. Here are the answers to your questions:

    • Regarding the failure rate and exact steps to reproduce:
      I want to clarify the exact sequence of events. The issue is almost 100% reproducible when following this specific flow. The failure happens specifically on the second erase attempt by the bootloader.

      Here are the exact reproduction steps:

      1. Initial Programming: Flash the MCU using J-Link (or XDS110).

      2. First Upgrade (Success): Boot into the bootloader and perform a firmware upgrade. The bootloader successfully erases the flash and writes the new application. Crucially, the new application is written such that in the final 1KB sector, ONLY the last 64 bits contain valid data (our CRC), and the rest of the sector remains 0xFFFFFFFF.

      3. Second Upgrade (Failure): Boot into the bootloader and attempt another firmware upgrade. The bootloader attempts to erase the flash sectors again.

      4. Observation: When the bootloader tries to erase that specific final sector (from Step 2), the STATCMD register reports PASS and DONE. However, a memory read reveals that the sector was not actually erased; the CRC data in the last 64 bits is still present.

      5. Workaround: If I modify the bootloader to write some dummy data to the first 64 bits of this final sector right before triggering the erase command in Step 4, the erase operation succeeds.

    • Regarding testing on another unit:
      I am currently developing and testing on an MSPM0G3507 LaunchPad. Unfortunately, I only have this single evaluation board available at the moment, so I cannot cross-check if this behavior occurs on other physical units.

    • Regarding XDS110 vs. J-Link:
      I tested this by switching to an XDS110 debug probe and using UniFlash for the initial firmware programming step (Step 1) instead of J-Link. The result is exactly the same. The first bootloader erase works, but the second erase fails silently unless I apply the workaround.

  • Hello Yiren,

    Thanks for your detailed explanation on this. I will check your response next Monday in details and reply to you as soon as possible.

    BR,

    Janz Bai