• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 805 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.

MSPM0L2228: Unable to connect SWD: DAP Connection Error

Robert Chen
Mastermind 9115 points
Part Number: MSPM0L2228
Other Parts Discussed in Thread: MSPM0G3507, LP-MSPM0G3507

Tool/software:

Hi,

I have a new project using XMSPM0L2228PMR. But the XDS110 debugger can't connect to it. The following error is shown:

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. 

To see the root cause, I run "Test Connection" from MSPM0L2228.ccxml and see the error:

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.

It seems that XDS110 can't see the target MCU.

To identify what's wrong, I soldered another PCB with only VDD, GND, VCORE, VBAT, SWDIO, SWCLK, NRST pins connected. Bypass and bulk capacitors are also soldered. VBAT is connected to VDD. 3.0V is measured on VDD and 1.35V is measured on VCORE. Unfortunately, the error is the same.

I have rich experiences about MSPM0G3507 with RHB and PM packages. Both packages are working well in my projects and I never encountered this kind of SWD error. I also compared the pinout of G3507SPM with L2228SPM. The key pinouts are the same.

I have checked the circuit/pinout/soldering again and again... Now, I believe it might be a silicon bug of XMSPM0L2228SPMR. If so, the chip design team should be aware of this issue before mass production. If there is any workaround, please let me know.

  • 0
    TI__Genius 16000 points

    Hi Robert,

    Have you tried putting the device into BSL mode before connecting with the debugger? You can do this by pressing and holding the PA18 button, then press and hold NRST for more than one second, then releasing NRST, then releasing PA18. Try this then immediately connecting with the debugger (as the device only remains in BSL mode for 10 seconds), and see if you can connect.

    Did you edit the NONMAIN memory at all, or disable debug access / BSL access to the device? Generally, what application code did you program to the device before this started?

  • 0 in reply to Dylan OBrien
    Mastermind 9115 points

    Hi Dylan,

    It is a customized PCB so there isn't PA18 button. But I have tested BSL mode by jumping wire from PA18 to VCC. NRST will be pulled low/high by debugger. The BSL mode was used to recover the system several times in my G3507 projects. So, I am pretty sure how to make it work. Since I can't access the device by debugger, the device is new and never programmed.

    Please notice that the chip used in LP-MSPM0L228 is "PN" package while it is "PM" package in my circuit. I can't verify it by LaunchPad. I don't have the LaunchPad neither.

  • 0 in reply to Robert Chen
    TI__Genius 16000 points

    Hm okay. 

    Have any MSPM0L2228SPMRs worked on this custom hardware? Is it possible that this is a PCB level issue? Would you mind posting an image of your schematic for the key device connections such as SWDIO, SWCLK, power supplies, Vcore? It would be helpful to verify this.

    Additionally, you say these are blank devices, these should start up in BSL mode as soon as they are powered on and manually putting them into BSL mode should not be necessary. 

  • 0 in reply to Dylan OBrien
    Mastermind 9115 points

    It is a new hardware and it is my first time to use L2228SPMR. But the MCU's symbol and footprint are copied (and modified) from G3507SPMR which is used in another project. The pinouts are basically the same, at least for power and SWD. Since G3507SPMR is working well then I think L2228SPMR should work, too.

    As I mentioned, VCORE is fine (1.35V). VDD is fine (3.0V). All connections from MCU pinout to SWD debugger pin-header is measured and confirmed by multimeter. I have done everything I can do. I really hope it is a mistake in my circuit. If not, TI should fix it before mass production.

  • 0 in reply to Robert Chen
    TI__Genius 16000 points

    Have you tried more than one MSPM0L2228SPMR chips on this hardware to rule out the possibility that the chip has some ESD damage?

    Have you been able to launch a target configuration and attempt to run the factory reset script in CCS? For this you may also want to try unplugging the device, holding nRST low, plugging it back in, and continuing to hold nRST low until you've been able to run the factory reset script. Partway through the running of the script you'll see the process stall, and at that point you should release nRST. Please let me know if you need further advice on this process.

    Also, you say you are confirming the debugger connections with a multimeter, do you have any logic analyzer to see the SWD communications? Can you see if the device responds at all to the debugger's communications?

  • 0 in reply to Dylan OBrien
    Mastermind 9115 points

    Thank you Dylan.

    Today, when I try to program one of my G3507 boards, the debugger won't work. That's strange because it was working yesterday. Then, I try to use the "XDS110 Out" interface of LP-MSPM0G3507 to connect my G3507 custom board. It works. So, I think my XDS110 debugger might be unstable. So, I also try the "XDS110 Out" interface to connect the L2228 custom board. It works!

    The root cause is the XDS110 debugger. It has been used for so many years. I guess the cable or the header becomes unstable. I need to get a new one. Before that, I will use LP-MSPM0G3507 to debug my target boards.