• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 79 subscribers
  • Views 279 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.

Original question:

MSPM0L1105: Flashing MSPM0L1105 using OPENOCD

MSPM0L1105: Flashing MSPM0L1105 using OPENOCD and SWD

Marc Murphy
Prodigy 60 points

Part Number: MSPM0L1105
Other Parts Discussed in Thread: LP-MSPM0L1306, UNIFLASH

We have a platform that has been designed to use the mspm0 micro as a co-processor to a AM6254 processor.  The system is running Linux 6.12.x kernel and has all associated I/O controls to allow for communicating with the mspm0l1105 micro.

image.png

We have cloned an built the latest openocd repository and were able to query and program the firmware we developed using the LP-MSPM0L1306 dev kit.

The firmware disables the SWD interface as we use the pins for alternative functions during normal operation.  To help us to debug we need to be able to update the firmware but cannot because the SWD is disabled.

I remember having to perform a sequence on the dev kit to allow for recovery when SWD was disabled and attempting to do this on our target hardware is proving problematic.

 

With openocd configured to use the nRST line to control the device reset state we can gain some communication with the device but not fully unlock it:

#openocd -f /home/debian/openocd-cfg/mspm0l1105.cfg
Open On-Chip Debugger 0.12.0+dev-02394-gb4518ab78 (2026-02-08-12:52)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Transport "swd" was already selected
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : SysfsGPIO JTAG/SWD bitbang driver
Info : Note: The adapter "sysfsgpio" doesn't support configurable speed
Info : SWD DPIDR 0x6ba02477
Info : SWD DPIDR 0x6ba02477
Error: [mspm0x.cpu] Could not find MEM-AP to control the core
Error: [mspm0x.cpu] Examination failed
Warn : target mspm0x.cpu examination failed
Info : [mspm0x.cpu] starting gdb server on 3333
Info : Listening on port 3333 for gdb connections

Is there an additional step required to allow successful SWD communitation?

 

  • 0
    TI__Mastermind 25112 points

    Hi Marc,
    If the SWD functionality was disabled in NONMAIN, there isn't way to revert back the unit to what it was before the SWD were disabled in NONMAIN. If the SWD lines are disabled by not changing NONMAIN, then the following should help restore the device to factory settings:

    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

  • 0 in reply to Diego Abad Sajamin
    Prodigy 60 points

    Hi Diego

    Thank you for your response.  Unfortunately the issue isn't on the LaunchPad board it is on our PCB that has the mspm0 processor connected to a Ti AM62x procesor.

    We are attempting to program using OpenOCD and the Ti support that is in OpenOCD.

    It is proving very difficult to create a recovery process using the tool.

    Some assistance from the relevant person responsible for maintaining the OpenOCD support would be appreciated.

  • 0 in reply to Marc Murphy
    TI__Mastermind 25112 points

    Hi Marc,
    To confirm, is the issue with the Ti AM62x processor's SWD being disabled, or with the MSPM0L? If the first is true, then I can change the thread to the AM62x for further support.
    Best Regards,
    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    Prodigy 60 points

    Hi Diego

    The issue is with the MSPM0L SWD.

    Thanks

    Marc

  • 0 in reply to Marc Murphy
    TI__Mastermind 25112 points

    Hi Marc,
    Ok, so in that case, do you need more clarity on how to change the software to disable the SWD in the MSPM0? I would need more details before I can reach out the team member in charge of the OpenOCD support.

    Best Regards,

    Diego Abad

  • 0 in reply to Diego Abad Sajamin
    Prodigy 60 points

    Hi Diego

    That is correct the use of MSPM0 and OpenOCD.

    Using something like this does not control the nRST line in the correct way.  It is held low while OpenOCD queries:

    adapter driver sysfsgpio

transport select swd

sysfsgpio swd_nums 593 519

sysfsgpio srst_num 681

# Configure SRST as output
reset_config srst_only srst_nogate connect_assert_srst

adapter srst delay 1100
adapter srst pulse_width 1100

source [find target/ti/mspm0.cfg]

init
#mspm0_factory_reset
mspm0_mass_erase

    Where we are trying to hold the reset for over 1 second to force POR.

  • 0 in reply to Marc Murphy
    TI__Mastermind 25112 points

    Hi Marc,
    Is the ASM controlling the NRST line for the MSPM0? If so, you will need to make sure the pin controlling the NRST drives it low so the device goes into a POR to be able to use SWD lines since during a POR the device configuration (as long as it wasn't modified in NONMAIN) will have the SWD functionality available. 

    If not the previous, which pin in the M0 are you using to reset itself?

    Best Regards,

    Diego Abad

**Attention** This is a public forum