MSPM0C1104: Factory Reset does not work

Part Number: MSPM0C1104
Other Parts Discussed in Thread: UNIFLASH

Seemingly at random my controller (MSPM0C1104 16pin) will fail a flash process, saying that it cannot connect to the target. 

Texas Instruments XDS110 USB Debug Probe/CORTEX_M0P Error connecting to the target: Connection to MSPM0 core failed. Possible root causes: 1) Debug access within NONMAIN was disabled or enabled with password. 2) Peripheral mis-configuration (e.g improper watchdog or clock). To see a more detailed diagnostic of the issue, please press the 'Read boot diagnostic' button. 

or

Texas Instruments XDS110 USB Debug Probe/CS_DAP_0 Error connecting to the target: DAP Connection Error. This could be caused by the device having gone to low power mode. Try forcing an external reset.If the error persists, try forcing BSL, a Mass erase or a Factory Reset. Check device FAQs for more information.

Usually any flash processes will succeed, dozens of times in a row. At max I will have to do a factory reset due to the reset line being disabled in the application. But once the issue occurs, it will persist for sometimes days, then suddenly disappear with a factory reset. Up to that point, any and all attempts to do a manual factory reset will fail, saying one of the following:

  • DAP Connection error
  • nothing at all but it will not succeed, instead saying to press the reset button

I do not access NONMAIN in any way. I do write to ROM, but there are no issues with that API as far as I can tell. For the factory reset I drain the board's capacitors, connect GND to NRST to ensure that the board will hold the reset before the initialisation, then connect my VDD, SWCLK, SWDIO lines to the debugger.

The strangest part is that this issue will persist across different targets, SW versions and even Launchpads that I am using for the flashing.

If I disconnect NRST from GND, I get the following log from the connection test:

Test Connections

-----[Print the board config pathname(s)]------------------------------------

C:\Users\USER\AppData\Local\TEXASI~1\
CCS\ccs2041\1\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Jan 9 2026'.
The library build time was '14:41:05'.
The library package version is '20.4.0.3835'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller to enter SWD mode.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[Perform the SWD Mode Integrity test]-----------------------------------

This test will read the IDCODE register 1 time.


-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-615' (0xfffffd99).
The title is 'SC_ERR_SWD_PROTOCOL'.

The explanation is:
The target failed to see a correctly formatted SWD header. The
connection to the target may be unreliable. Try lowering the
TCLK setting before trying again.

  • Hi RH,
    Let's try to narrow down what could be the issue. Can you try to connect the device core's with a project-less debug? Let me know what are the results:
    1. Right click in the projects' .ccxml file, and left click in Start Project-less Debug:

    2. Click in "Show All Core"

    3. Check which cores you are able to connect to

    Best Regards,

    Diego Abad

  • Hello Diego,

    1. This works. Mind you, I do have NRST connected to GND.

    3. CORTEX_M0P, CS_DAP_0 and SEC_AP show DISCONNECTED. No other cores appear.

    Kind Regards

  • Hi RH,
    What happens when you right click in any of the cores and click connect? Do any cores shows an error?

    Best Regards,

    Diego Abad

  • All 3 report the same DAP Connection error. Which is why I assumed that either the device is in low power mode or that there is an issue with the bootloader/NONMAIN memory.

  • I have a different case now. I can connect to 2 of the cores but the factory reset yields no result, staying stuck at "Press the reset button".

  • Hi RH,
    What is the error that shows when you try to connect to the CORTEX_M0P?

    Best Regards,

    Diego Abad

  • Hello Diego,

    Error connecting to the target:  Connection to MSPM0 core failed.  Possible root causes: 1) Debug access within NONMAIN was disabled or enabled with password. 2) Peripheral mis-configuration (e.g improper watchdog or clock).  To see a more detailed diagnostic of the issue, please press the 'Read boot diagnostic' button.

    Best Regards

  • Hi RH,
    This message normally means that your SWD connections are good (since you can connect to other cores) but the device is locked/bricked. Can you try the following and see if it unlocks the device:
    1. Disconnect the LaunchPad from power
    2. Open a Uniflash session for the device (Check both device and debugger, or select the launchpad image)
    3. Press and hold the NRST button (S3).
    4. Connect the LaunchPad to power while continuing to hold the NRST button
    5. Click on the "Setting & Utilities" tab and click on/Issue a manual Factory Reset DSSM command
    6. Release the NRST button when the console prompts you to press the NRST button

    Best Regards,

    Diego Abad

  • Hello Diego,

    as mentioned previously, any attempts to do a factory reset do not finish. I did try it specifically with Uniflash as well but am currently receiving DAP connection errors.

    How can this happen that my device is bricket? Perhaps during a factory reset if the connection is interrupted?

    Kind Regards

  • Hi RH,
    That could the reason. Other reasons include NONMAIN not being configured properly, or accidently changing its contents. a hardware issue in the device due to outside sources, and the less likely reason, a defect in the device. How many units are experiencing this issue?

    Best Regards,

    Diego Abad

  • Hello Diego,

    it happens occasionally. I have experienced this issue on 3 units with which I have worked regularly. I am not certain about their common traits but I believe it to be a faulty factory reset.

    Kind Regards