• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 359 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.

LP-MSPM0C1104: MSPM0C1104 not accessible after flashing – DAP error, only responds during reset, Mass Erase unavailable

Janet Kurian
Prodigy 10 points

Part Number: LP-MSPM0C1104
Other Parts Discussed in Thread: MSPM0C1103, MSPM0C1104, , UNIFLASH

Hi Team,

I am facing a critical debug access issue with the LP-MSPM0C1104 LaunchPad after reconfiguring PA19 and PA20 as GPIO. My intention was to match the target PCB design, where the actual device is MSPM0C1103 (8-pin variant), and PA19/PA20 are required as GPIO. Based on this, I configured these pins as GPIO in my application and flashed the MSPM0C1104 LaunchPad.

Observed Behavior

  • CCS error:

    CS_DAP_0: Error connecting to the target: DAP Connection Error
  • SWD Test Connection:
    • IDCODE read is successful only when reset button is pressed
    • IDCODE = 0x6ba02477 image.png
    • Outside reset window → communication fails image.png
  • UniFlash/GEL output: 
    • Mass Erase is not available for this device
    • DSSM Mass Erase → fails
    • DSSM Factory Reset → fail

image.png

  • Could configuring PA19/PA20 as GPIO disable or interfere with SWD/debug access on MSPM0C1104?
  • Is there a recommended way to safely use these pins as GPIO without losing debug access?
  • Are there additional recovery mechanisms beyond DSSM Mass Erase / Factory Reset?
  • Is this condition recoverable, or is the device effectively locked?
  • How can I determine whether the issue is with U1 (target MCU) or U2 (onboard debugger/XDS110)? 
  • How can the MSPM0C1104 be programmed in standalone mode (without the onboard debugger)?

No intentional debug/security configuration was applied. Issue occurred immediately after flashing user application.

Any guidance on recovery or correct SWD-safe GPIO configuration would be greatly appreciated. 

Regards,

Janet 

  • 0
    Prodigy 20 points

    Hey Hi

    I stuck in same situation yesterday, 

    You MCU actually executing I2C over debug pins so not getting enough time to start debug session, do as following 

    (1) Keep reset button pressed and power on device, do not release reset button otherwise your main code start executing and your debug pin will no longer work, in short Keep reset button pressed and power on device and don't leave reset button 

    (2) Open UniFLash utility, press factory reset auto, then release reset button after 1-2 seconds, you might get error like registers inaccessible and blah blah, but observe there must no DAP or connection error. Then power cycle board, repeat this step 1-2 times every time power cycle system. 

    (3) After this reconnect board and Uniflash -> Memory -> Read Target Device, 

    (4) If read successful then flash some basic GPIO toggle program , 

    (5) this worked for me , hope work for others also 

  • 0
    TI__Mastermind 26372 points

    Hi Janet,
    Apologies about the lates response:

    I. Yes. However, as long as the change it's only to GPIO functionality, it can be reversed.

    II. You can try to add a small delay before changing the GPIOs to SWD functionality. That way, every time you reset the device, you'll have a small window before the SWD lines change functionality, which allows you to access the device. 

    III. Yes. The following sequence should unlock your device (if it's still not unlocked, you can assume your device is bricked):

    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

    IV. If the previous didn't work, the device is locked

    V. You can try using the XDS110 in another device. If it's able to program the other device, the issue relies on the previous MSPM0. If it can't, the issue relies in the XDS110.

    VI. You will need to program it with an external XDS110. 

    Best Regards,

    Diego Abad

**Attention** This is a public forum