• State TI Thinks Resolved
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 344 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM33C321A: how to do sector erase

Jerry Kuo
Expert 4870 points

Part Number: MSPM33C321A
Other Parts Discussed in Thread: UNIFLASH

Hi team,

 

One flash programming vendor is experiencing issues with Flash erase and would like to confirm the correct procedure for Sector Erase.

 

Background

  • Hardware and setup: Same IC, same programming algorithm, and same hardware setup.
  • Full Chip Erase (Working):
    1. Send DSSM Factory Reset command via SEC-AP Mailbox (TCR = 0x020A, TDR = 0x00000000).
    2. Perform NRST hardware reset and re-initialize the SWD connection.
    3. Acquire Flash Semaphore successfully.
    4. Execute Bank Erase (CMDTYPE = 0x52) to finish full chip erasure.
  • Sector Erase (Failing):
    • We need to keep data in some Flash areas, so we changed the method to Sector Erase (CMDTYPE = 0x42, erase specific sectors only).
    • We removed Factory Reset from the flow to avoid clearing the protected data, but the erase process fails.

Symptoms

  • The sector erase process gets stuck at the Acquire Flash Semaphore stage.
  • According to the SDK example, before running Flash Erase/Program, we get the Flash Semaphore:
    1. Write to GSC_FPC_FLSEMREQ.
    2. Read GSC_FPC_FLSEMSTAT to confirm success.
    3. Poll steps 1 and 2 until the semaphore is acquired.
  • During sector erase, reading GSC_FPC_FLSEMSTAT always returns 0x00000000, meaning the semaphore cannot be acquired.

Logic Analyzer Observations (SWD Waveform)

  • SWD connection is normal: IDCODE reads correctly (0x6BA02477), and powering up DebugPort or halting the CPU works fine.
  • When the CPU is halted at the reset vector (boot code not yet executed), reading GSC_FPC_FLSEMSTAT via AHB-AP always returns a FAULT (bus error) across multiple retries.

Questions for Vendor Support

  1. What is the standard procedure for performing a Sector Erase / Program via SWD without executing a Factory Reset?
  2. What are the potential causes for the Acquire Flash Semaphore failure described above? Please let us know if you need any additional information.
  • 0
    TI__Intellectual 2200 points

    Hello Jerry, 

    Thank you for the detailed description here. In the meantime, can you point me to the exact SDK example being referenced here? 

  • 0 in reply to JOJO ARTHUR
    Prodigy 60 points
    • We did not use the SDK, nor did we have any sample code for it. However, there are relevant waveforms.波形.zip
  • 0 in reply to MING CHEN
    TI__Intellectual 2200 points

    Hello Ming,

    Thank you for sharing the waveforms.

    Regarding the sector erase operation, acquiring the Flash semaphore is one of the first required steps before the erase operation can proceed. Since the semaphore acquisition is where the current sequence appears to be getting stuck, could you please share the AHB-AP CSW configuration being used for the debugger accesses?

    The TRM explicitly states that GSC_FPC_FLSEMREQ, GSC_FPC_FLSEMCLR, and GSC_FPC_FLSEMSTAT can also be accessed from a Non-Secure context, even when the GSC is configured Secure. However, the TRM does not explicitly state whether the same exception applies to the privilege attribute. Since the GSC has a separate privilege-access configuration, I would like to double-check the privilege attribute being generated by the AHB-AP transaction when accessing these registers.

    Also, our SDK includes Flash examples, such as flashctl_multiple_size_write, that use the appropriate GSC and Flash Controller register definitions. Could you please confirm that the addresses used by your programming algorithm for FPC_FLSEMREQ and FPC_FLSEMSTAT match those used in the SDK/device header?

    Regarding the AHB-AP FAULT observed when halting the CPU at the reset vector before the boot code executes, I do not believe that this is the primary issue in this case. At that point, the normal boot/security initialization may not yet have completed. For now, I would suggest focusing on the semaphore acquisition after the normal boot sequence has completed.

  • 0 in reply to JOJO ARTHUR
    Prodigy 60 points

    Regarding CSW configuration: The debugger has configured the AHB-AP's CSW register to 0x23000012. Since secure debug authentication has not been performed, the transaction attributes are Non-Secure + Privileged.

    Regarding register addresses: Verified against the SDK header files, the algorithm uses 0x50047800 for FPC_FLSEMREQ and 0x50047808 for FPC_FLSEMSTAT, consistent with SDK definitions. Previously, addresses 0x40047800 / 0x40047808 were also used, but exhibited identical behavior.

    Regarding operation timing: Modified as per your suggestion—no longer using reset vector capture. After reset, the core is allowed to run freely for approximately 500ms, halted only after boot completion, followed by semaphore acquisition. However, the issue remains unchanged: when issuing an AHB-AP read access to FLSEMSTAT, RDBUFF returns a FAULT ACK.

  • 0 in reply to MING CHEN
    TI__Intellectual 2200 points

    Hello Ming,
    Thank you for the additional details. I believe the CSW value provides an important lead. According to the Cortex-M33 AHB-AP definition, CSW[30] controls the security attribute of the generated AHB transaction, where 0 requests a Secure transfer and 1 requests a Non-Secure transfer. CSW[25] controls privilege, where 1 indicates Privileged.
    Therefore, with CSW = 0x23000012, bit 30 is currently 0, so the transaction is requesting Secure + Privileged, rather than Non-Secure + Privileged. Since you mentioned that Secure debug authentication has not been performed, this may explain the FAULT response.


    Could you please try the following sequence:
    1 Clear any existing SW-DP sticky error (ABORT.STKERRCLR) before issuing another AHB-AP transaction.
    2 Configure the AHB-AP CSW for an explicitly Non-Secure + Privileged, 32-bit transaction. Based on the Cortex-M33 CSW definition, please try 0x43000012.
    3 Read the CSW back and confirm that CSW[30] = 1 and CSW[25] = 1.
    4 Use the Non-Secure semaphore addresses:
    ◦ FPC_FLSEMREQ = 0x40047800
    ◦ FPC_FLSEMSTAT = 0x40047808
    5 First read FLSEMSTAT. If ASSIGNED = 0, write 1 to FLSEMREQ.REQ and read FLSEMSTAT again.
    If the acquisition succeeds, we would expect ASSIGNED = 1, MATCH = 1, DBGACC = 1, PRIV = 1, and SEC = 0 when read back through the same debug context.
    If the read still returns a FAULT after this change, could you also provide the AHB-AP CSW readback value and DP CTRL/STAT value immediately before and after the failing access?
    The fact that the same algorithm succeeds following Factory Reset may also be consistent with this, since Factory Reset restores the NONMAIN/debug configuration to its default state.

    Regards, 

    Benedict Jojo

  • 0 in reply to JOJO ARTHUR
    Prodigy 60 points

    The test has been completed according to the suggested sequence, with the following results:
    CSW is configured to 0x43000012; before access, CSW reads back as 0x43800052, DP CTRL/STAT = 0xF0000040.
    Subsequently, a read access to FLSEMSTAT (0x40047808) was initiated, and RDBUFF returned ACK FAULT. Immediately after the failed access, reading back CSW shows that the AP read request returns ACK FAULT, and DP CTRL/STAT = 0xF0000020.
    Attached waveform file for reference.

    Erase.zip

  • 0 in reply to MING CHEN
    TI__Intellectual 2200 points

    Hello Ming,
    Thank you for the additional results and waveform. The latest values help narrow the issue significantly.
    The CSW readback of 0x43800052 confirms that the AHB-AP transaction is now configured as Non-Secure + Privileged, so the security/privilege attributes themselves do not appear to be the cause.
    The CTRL/STAT transition from 0xF0000040 to 0xF0000020 is also important. Before the FLSEMSTAT access, READOK=1 and STICKYERR=0. Following the access, READOK=0 and STICKYERR=1, indicating that the memory access to 0x40047808 itself is returning an error. The subsequent FAULT when reading CSW is therefore expected while the DP sticky error remains set.


    Before each subsequent test, please clear the SW-DP sticky error using ABORT.STKERRCLR.
    Could you next perform two checks:
    1 Using the same 0x43000012 CSW, confirm that a read of a known Non-Secure SRAM location or ordinary Non-Secure peripheral succeeds before attempting 0x40047808.
    2 After clearing STICKYERR, configure the CSW as 0x03000012 (without the reserved bit set here) and try a read of the Secure alias 0x50047808. Please provide the CSW readback and CTRL/STAT before/after this access.


    Additionally, could you provide the active debug security configuration / NONMAIN BOOTCFG0.DEBUG_ACCESS setting on the device before Factory Reset? If possible, please also provide the value following Factory Reset for comparison.


    The reason for this check is that the TRM explicitly grants Non-Secure code access to the FLSEM registers, while the external debugger has a separate debug-security policy. Since Factory Reset restores the NONMAIN/debug configuration to its defaults, I would like to determine whether the AHB-AP is being blocked from accessing the GSC by the active debug policy before the request ever reaches the FLSEM register.

  • 0 in reply to JOJO ARTHUR
    Prodigy 60 points

    After testing with the CSW configuration you suggested, semaphore acquisition and sector erase were successful, and the entire erase process completed without any faults.

    However, we later observed a new phenomenon: after successfully completing erase, program, and verify operations, upon power cycling, reading back the flash content resulted in all data being 0xFF.

    For comparison, we used UniFlash to program TI's official example code—the blink LED demo. UniFlash indicated successful programming and passed verification; yet, after power cycling and reading back using UniFlash again, the content was also entirely 0xFF.

  • 0 in reply to MING CHEN
    TI__Intellectual 2200 points

    Hello Ming, 

    I am glad the sector erased worked successfully. In order to ensure we have a consistent workflow, could you upvote my previous answer and open up a new thread based on this new issue? I will pick that up so we can continue working on this. 

**Attention** This is a public forum