• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 310 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.

MSPM0L1228: MSPM0L1228 locked - DAP error 0x00010136 and SECAP_RCR access failure

xiaobing ye
Prodigy 50 points

Part Number: MSPM0L1228
Other Parts Discussed in Thread: UNIFLASH, MSPM0L2228, SYSCONFIG

Dear TI Support Team,

I am encountering a critical issue while trying to recover an MSPM0L1228 device using Code Composer Studio (CCS) and an XDS110 debugger.

After a previous experiment involving NONMAIN configuration, the device can no longer be accessed through the DAP interface. The CCS console shows:

CS_DAP_0: Device diagnostic read = 0x00010136
CS_DAP_0: Trouble Reading Register SECAP_RCR: (Error -2131 @ 0x2020C)
Unable to access device register. Reset the device, and retry the operation.

I have already tried the following recovery procedures:

  1. Power-cycled the board and reconnected XDS110 (COM4).

  2. Executed the following CCS scripts under MSPM0L1228_Commands:

    • MSPM0_Mailbox_FactoryReset_Auto

    • MSPM0_Mailbox_WaitForDebug_Auto

    • MSPM0_Mailbox_FactoryReset_Manual

  3. Lowered SWD clock frequency to 100 kHz.

  4. Verified that XDS110 firmware is up to date.

  5. Attempted UART BSL connection via UniFlash (Factory Reset mode).

Despite all these steps, the DAP repeatedly shows:

CS_DAP_0: SEC_AP Disconnect
CS_DAP_0: SEC_AP Reconnect

and the Mailbox commands never complete successfully.

Could you please help confirm:

  • Whether this condition indicates a DSSM or NONMAIN permanent lock on MSPM0L1228?

  • Is there any hardware or ROM-based recovery method (e.g., forcing BOOTRST or using UART BSL) still available in this state?

  • If the device is unrecoverable, could you provide guidance on verifying the NONMAIN region integrity or using low-level mass erase commands?

Both boards are otherwise electrically sound and have not suffered physical damage.

Thank you very much for your assistance.

  • 0
    TI__Mastermind 26940 points

    Hi Xiaobing,

    I believe the NONMAIN was improperly programmed due to the error message you've received. You can try to hold the NRST pin down then send the DSSM commands but depending on the nonmain settings you could still get rejected. The parts might be inaccessible now due to the nonmain settings/erasure.

    We have nonmain code examples in the SDK, C:\ti\mspm0_sdk_2_06_00_05\examples\nortos\LP_MSPM0L2228\driverlib\flashctl_nonmain_memory_write

    I do recommend using SYSCONFIG to program the NONMAIN component so all the settings are correct to prevent accidental locking of the part.