• State
  • Replies 11 replies
  • Subscribers 53 subscribers
  • Views 99 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MSPM0G3519: CCS 20.5, LP-MSPM0G3519 (XDS110) Sysctl_resetDevice disconnects debugger... (CORRECTION- BREAKPOINTS FAIL)

Ken Ayre
Prodigy 120 points

Part Number: MSPM0G3519

>>EDIT ADD >> The baseline issue is that after a BOOT RESET the debugger is running, and can be paused- and reports values and registers properly.  But, after a BOOT Reset, breakpoints fail until a manual Disconnect and Connect of the MSPM0 core in "threads"

______

After the Debugger disconnects on Sysctl_resetDevice, and we need it to automatically re-connect (or not fully disconnect).   

Manual reconnect /attach to running target does work, but it can't be done quick enough to hit a breakpoint in my Check_SDI_Restart().

Our code invoke a reboots for a few reasons, and on restart attempt recovery or collect metrics.  This wil also be an entry point for future custom reprogramming.

I've been going through properties and settings for a few hours without finding what I am looking for.

  • 0
    Prodigy 120 points

    The behavior just changed, and even when the debug window shows "THREADS>CORTEX_M0P  RUNNING", hardware breakpoints are ignored.   Debug properties were changed to add 

     <property id=\"AutoRunToLabelOnReset\"> to launch.json
    But breakpoints and watches are still not available.
  • 0
    TI__Guru**** 483541 points

    Hello,

    Ken Ayre said:
    After the Debugger disconnects on Sysctl_resetDevice, and we need it to automatically re-connect (or not fully disconnect).   

    Depending on how the reset is handled, you may be able to try the OnResetDetected() callback to call GEL_Connect() to reconnect to the CPU. Again it will depend on how the Sysctl_resetDevice works but it is worth a try.

    Thanks

    ki

  • 0 in reply to Ken Ayre
    TI__Guru**** 483541 points
    Ken Ayre said:
    The behavior just changed, and even when the debug window shows "THREADS>CORTEX_M0P  RUNNING", hardware breakpoints are ignored.   Debug properties were changed to add 

    Is the CPU still disconnected? If so, then the HW breakpoints would not trigger.

  • 0 in reply to Ki
    Prodigy 120 points

    After adding  <property id=\"AutoRunToLabelOnReset\"> to the launch, the CPU is "reportedly connected", i.e. debug panel shows "THREADS> CORTEX_M0P RUNNING.

  • 0 in reply to Ken Ayre
    TI__Guru**** 483541 points

    That action just tells the debugger to run to main (or other specified label) after program load. It would only apply when then first launching a project debug session.

  • 0 in reply to Ki
    Prodigy 120 points

    Hmmm?    Doesn't make sense.   And honestly, I'm not sure of the suggestion OnResetDetected() callback to call GEL_Connect(). Is that source code, or a script someplace?

  • 0 in reply to Ken Ayre
    TI__Guru**** 483541 points
    Ken Ayre said:
    I'm not sure of the suggestion OnResetDetected() callback to call GEL_Connect(). Is that source code, or a script someplace?

    You would add this to the device GEL startup script:

    https://software-dl.ti.com/ccs/esd/documents/users_guide_ccs/ccs_debug-gel.html

  • 0 in reply to Ki
    Prodigy 120 points

    got it-I  worked through the most basic  part of GEL learning curve last night

    Unfortunately, OnResetDetected() does not trigger with software invoked resets- but it appears to trigger multiple times during debug session start.

    I find it hard to believe we're the only group that needs to debug coming out of reset.

  • 0 in reply to Ken Ayre
    Prodigy 120 points

    I'm still looking for a way...in the mspm0g3519.gel, routines like "MSPM0_ResetCtl_WaitForDebug()" and "MSPM0_Mailbox_WaitForDebug_Auto()" get my attention.  There are other similar functions.   Are these relevant?

    Worst case- if the xds110 debugger cannot work, is there a higher end debugger that may have better control?

  • 0 in reply to Ken Ayre
    Prodigy 120 points

    I should add some additional information.... this is a FreeRTOS project.   After any reset except POR types, we see the debugger still running, <EDIT>although not in sync with the target<INCORRECT>.  I don't know why it took me this long to wonder what happens if I PAUSE the debugger.  

    The debugger is in FreeRTOS land, stuck in a loop... <<EDIT  No it is doing exactly what it is suppsed to- just ignoring all breakpoints.

    static void prvCheckTasksWaitingTermination( void )
    ....
    while( uxDeletedTasksWaitingCleanUp > ( UBaseType_t ) 0U )
  • 0 in reply to Ken Ayre
    Prodigy 120 points

    Summary:  For SYSTEM Resets, setting a breakpoint at Reset_Handler halting there shows the debugger IS tracking the reset and flow can be stepped all the way to main().

    The BOOT reset is what is causing problems.  The breakpoint i placed at Reset_handler is never reached.  OnResetDetected is not triggered.

    On return from BOOT reset, CCS still sees the core as "running", but breakpoints are non-functional.  Breakpoints placed before the BOOT_RESET, and newly placed breakpoints do not trip.

    After a BOOT Reset, the debugger can be successfully paused and restarted- and variables, call stack, registers, and Threads are updated- so the debugger knows the target is there- just breakpoints fail.

    Possible work-around (not tested in depth)... Right click on "CORTEX_M0P" and "disconnect", then right click "connect".  GEL will respond "Memory Map Initialization Complete" and breakpoints appear to be repaired.

    Similarly, a POR reset can be reconnected.

    It still remains that we cannot recover debugging operation quickly enough to stop at get_reset_cause and pulling shutdown status bytes.   

    Even worse, #ifdef DEBUG __BKPT() #endif will cause a hard fault under these conditions.