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.

Compiler/CC3220SF-LAUNCHXL: Help in finding documentation

Part Number: CC3220SF-LAUNCHXL

Tool/software: TI C/C++ Compiler

Hi! I'm not able to find which documents describe the following topics:

  • how to attach the debugger XDS110 to an already running MCU (without resetting it, of course)
  • how to customize the various system ISR (like FaultISR) to avoid hanging in a forever loop

Would you mind to provide me a link to the related documents?

  • Hello,
    Are you trying to do a non-intrusive connect (do not halt target when connecting debugger to target) or simply trying to avoid a reset (but otherwise halting the target on connect?

    As for the second question, I will let the device experts in this forum answer that one.

    Thanks
    ki
  • Dear Mark81 -
    please see this E2E post on the topic of connecting XDS110 to CC3220, using CCS the way you desire.

    e2e.ti.com/.../588229

    Handling of ISRs are discussed here: www.ti.com/.../swru465.pdf (multiple places)
  • Are you trying to do a non-intrusive connect (do not halt target when connecting debugger to target) or simply trying to avoid a reset (but otherwise halting the target on connect?


    I'm trying to avoid both a reset and a reprogram of the firmware. Right now when I launch a debug session the MCU is resetted, then the firmware is download (even if there are no changes) and that it starts from the beginning (entry point).

    Instead, I need to attach a debug session on a running target without any reset or fw download. It's ok if it halts in the current state in the way I can see the code that is executing and continue the debug from there. This because I can debug only the first couple of seconds of my application, after that it enters in hybernation and when it wakes up I cannot continue my debug.

  • Handling of ISRs are discussed here: www.ti.com/.../swru465.pdf (multiple places)

    I apologize, I was talking about how to handle them in CCS. I mean where I have to put the handlers and how to write a production-oriented isr for such a fault.
  • Mark81 said:

    I'm trying to avoid both a reset and a reprogram of the firmware. Right now when I launch a debug session the MCU is resetted, then the firmware is download (even if there are no changes) and that it starts from the beginning (entry point).

    Instead, I need to attach a debug session on a running target without any reset or fw download. It's ok if it halts in the current state in the way I can see the code that is executing and continue the debug from there. This because I can debug only the first couple of seconds of my application, after that it enters in hybernation and when it wakes up I cannot continue my debug.

    I see. 

    What you want to do is a "manual launch"

    http://software-dl.ti.com/ccs/esd/documents/users_guide/sdto_ccs_debug-handbook.html#manual-launch

    Thanks

    ki

  • Thanks! I was able to connect to a running target without issuing a reset!
    From the document above it's not clear to me how to set breakpoints. When I try to set one it is labelled "SW disabled" and of course won't trigger.
  • Dear Mark81 - 

    if using CCS or IAR, you should be able to double click in the column next to the line of code to set a breakpoint and compile to debug. It will show up as a ball symbol. If you have a specific example screenshot of what you are trying to set a breakpoint on, we can advise further.

    for graphic example, see the symbol next to line 81 below, to remove the breakpoint, double click again and recompile: 

  • Yes, this is the usual way to set a breakpoint but it works ONLY if I launch a debug session downloading the firmware. If I do the same after attaching the debugger on a running target, the blue ball is gray with a small yellow triangle and a tool tip says: "SW disabled". I can't provide a screenshot right now - I hope my description is quite accurate.

    To summarize:

    1. launch a standard debug session: CCS will compile, connect, download and run the code
    2. after the MCU enters in hybernation the debugger is disconnected from the target
    3. using a manual launch I can reattach it to the target after a wake-up
    4. right-clicking on the core and select "connect" leads CCS to break the target to the current execution line (likely disassembled code)
    5. to return to a C code of my program I set a breakpoint in the main-loop but as said CCS doesn't show the standard blue ball but the warning symbol and disables the newly created breakpoint
  • Dear Mark81 -
    i can see this wiki covers the topic (it says Stellaris, but also covers M3/M4 in general, for CCS) - not sure its up to date - will ask internally to the CCS team whether they have an update to this page information - as this is advanced debug question on the compiler - the details from you help for sure.

    processors.wiki.ti.com/.../Watchpoints_for_Stellaris_in_CCS
  • Hi Mark,

    Mark81 said:
    Yes, this is the usual way to set a breakpoint but it works ONLY if I launch a debug session downloading the firmware. If I do the same after attaching the debugger on a running target, the blue ball is gray with a small yellow triangle and a tool tip says: "SW disabled". I can't provide a screenshot right now - I hope my description is quite accurate.

    If you do a manual launch, you still need the load the debug symbols to the debugger to be able to have source level debug functionality (like source line breakpoints). 

    Please see the below video for an example:

    http://dev.ti.com/tirex/#/?link=Development%20Tools%2FIntegrated%20Development%20Environments%2FCode%20Composer%20Studio%2FDebug%2FQuick%20Tips%2FDebugging%20Program%20in%20Flash%20(YouTube)

    Thanks

    ki