• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 30 subscribers
  • Views 387 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.

MSPM0L1306: DSLite / Uniflash cannot trigger POR to re-enable the SWD port if FW disabled it

Tiger Wang
Prodigy 155 points
Part Number: MSPM0L1306
Other Parts Discussed in Thread: SYSCONFIG, UNIFLASH

We recently want to use SWD pins as alternate function. Ans we are using the sysconfig to generate the initialization code. However, we had some issue on that. The SWD no longer available after download the program which contains this change.

I see that SYSCFG_DL_DEBUG_init() is after the SYSCFG_DL_GPIO_init(). However, in the RM:

To disable SWD functionality, set the DISABLE bit in the SWDCFG register in SYSCTL along with the KEY. Then configure IOMUX for the desired functionality.

Once the SWD pin functions are disabled, they can only be re-enabled by triggering a POR.

Is this a sysconfig tool bug?

I tried to run our application with generated code. Yes, the SWD port is disabled, now we cannot Flash it anymore. However, question is:

I saw the RM that SWD will re-enable after a POR (NRST >1s). Why neither online Uniflash nor local DSLite tool can reset the target properly and attach the device? I always received the DAP_0 fail message (and ask me if I want to force reset the board, but keep failing).

Our program is run on application partition, so a bootloader is present. The bootloader will load the APP ~1s later, so I think the debugger has time to enter debug mode and skip the APP FW setting.

Currently, we have to OTA our software to a FW that don't disable the SWD. Then power-cycle the device, the SWD is recovered.

  • 0
    TI__Mastermind 29075 points

    Hello Tiger,

    It sounds like you are disabling the SWD and using it as a GPIO and that is working.  Is that correct? 

     Most likely what is happening when you try to program is you reset the SWD function via a POR, but then immediately the init code disables the SWD function.  So the timing of connection window is very short.   If the built in BSL is still enabled, you can trigger it using the external BSL Invoke pin and this can buy you ~10 seconds before the application code runs to re-connect via the SWD.  If you’re using a launchpad, S1 (PA18) is used for this.  Hold this button while resetting to see if you can regain access. 

    Thanks,

    JD