• State TI Thinks Resolved
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 84 views
  • Users 0 members are here
Support feedback
Options
Options
Related

LP-MSPM0G3519: MSPM0G3519

James Bregar
Prodigy 10 points
Part Number: LP-MSPM0G3519
Other Parts Discussed in Thread: SEGGER

Tool/software:

When performing some initial IWDT testing with the MSPM03519 Launchpad development kit, we noticed that if the watchdog expires on device, we're unable to reprogram/debug the MCU via SWD.  To verify this wasn't specific to our code we implemented the iwdt_periodic_reset_LP_MSPM0G319_nortos_ticlang project.  There was no issue compiling and/or debugging the test project as it, however when we commented out line 69: DL_IWDT_restart(IWDT_INST); the SWD disconnected from the MCU and we were no longer able to debug.

Using Segger Jflash 8.62 we could attach the debugger, erase the main memory, and we were able to recompile, re-download, and debug without the IWDT enabled.  I believe this maybe a similar issue to what is has been confirmed with the L2228 device.  We would like to confirm if this is an issue with the MSPM03519 and if there is a recommended workaround, as we’re currently just disabling the IWDT during development. Additionally, if there is a way for the firmware to detect if the SWD connector is attached via MCU registers (or other technique) it would be helpful to allow us to disable the watchdog during debugging only.

  • 0
    TI__Prodigy 490 points

    Hi James,

    When the IWDT expires, it is forcing a POR which disconnects the device from the debugger. When disconnected, the application code doesn't stop. In this example without the IWDT resetting, the device is resetting over and over. This is why the debugger cannot reconnect without erasing the application code from main memory. 

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    Prodigy 10 points

    We primarily used the example code to just confirm that the debugger was being disconnected from the target on the reset, however our proprietary application has the IWDT set initially to expire quickly during our power on reset test as we're required to validate the peripheral on startup to comply with our ASIL B standards.  After the first expiration we lose connection to the debugger and have to reflash the code.  If we're able to detect if the DAP/SWD is connected, we can disable this test, or we have to disable the IWDG itself in order to be able to continue to debug.  Do you know if it's possible to read the status of the SWD from the MCU itself to allow for the IWDG test to only be executed when there is no debugger attached?

  • 0 in reply to James Bregar
    TI__Prodigy 490 points

    Hi James,

    It is possible to detect when the debugger is connected/disconnected. You can utilize the DEBUGSS PWRUPIFG interrupt for when the debugger connects, and the PWRDWNIFG interrupt when the debugger disconnects.

    There currently isn't an implementation of X_getPendingInterrupt(), but you can still do a bitwise comparison of the RIS and chosen interrupt.

    For example, the following will reset the IWDT when the debugger is connected:

    if (DEBUGGS->CPU_INT.RIS & 0x04 ==0x04) {
        Reset IWDT
    }

    Reading the RIS will not reset the interrupt, allowing it to be continuously polled.

    Best Regards,
    Brian

  • 0 in reply to Brian Lee
    Prodigy 10 points

    Brian -

    This looks like it will help solve our issue.  We'll give this a try!  Thank you for your help clarifying the IWDT behavior and method for detecting the debug tap.

    Regards,

    James