• Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 4935 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.

Resetting the CPU and restarting a debug session.

Roger Wolff
Intellectual 550 points

Sometimes I want to restart my (compiled-for-flash) program in my target. 

When I click the reset CPU button, it looks  as if the CPU correctly resets, but the debugger loses connection with the target and the only thing I can do is to click the "debug" button again, which then tells me it needs to cancel the old debug session and proceeds to reflash my chip. As this takes a lot of time, I would like to be able to just "reset the CPU'. 

When I push the button on the target board, the CPU resets, halts at 3ff5f5, and then the debugger mentions: no source code. Then hitting "go/run/resume" will immediately halt again, and the watched variables remain in the "as before the reset".

So: how do I reset/restart my target without reinitializing the debugger and reflashing my target?

  • TI__Guru**** 171729 points
    Hi,

    What is the exact device you are using, and what is the message or what is shown when you say the debugger loses connection with the target?

    Usually issuing a CPU reset from the GUI does not reset the JTAG connection, but sometimes it simply disconnects the core and gives the impression the connection was lost. To restore connection, simply right-click on the core and select Connect.

    When you are actually pressing a reset button on the board, the core may also get disconnected. In this case, I strongly suggest you to disconnect the core first (right click on the core and select Disconnect), reset the board, then re-connect. This tends to avoid any loss of sync between the JTAG debugger and the running target.

    After the device is reset and the core is connected, the code is already loaded (in case of flash devices) and you just need to re-load symbols and be able to debug it. To do that, go to menu Run --> Load --> Load Symbols and point to the .out file you have.

    Certain parts of the code do not have source code tied to it, but this is normal. Check:

    e2e.ti.com/.../1151754

    A general overview of the debugging process and several of the items I mentioned are shown in the Debug Handbook page:

    processors.wiki.ti.com/.../Debug_Handbook_for_CCS

    Hope this helps,
    Rafael
  • in reply to desouza
    Intellectual 550 points

    I have a launchpad with 28027 processor. 

    A window that normally doesn't tell me anything suddenly shows a bunch of text in red. It overflows the window. I haven't paid attention to what it says. But the effect is that I can't use any of the debugging buttons anymore. 

    The reconnect sounds like it could be the solution: I don't need to "connect" on the first "start the debugger", so I didn't know that existed. 

    Why would resetting the core also flush the symbols? When I'm debugging <other brand> CPUs when i hit the hardware reset, the debugger (gdb) says something like "signal recieved" and has the processor halted at the reset vector, hitting "c" runs the program from the reset vector. 

    (To me it is acceptable that when starting a debug session it flashes the code once. But I would like to be able to go back to the beginning without having to restart the whole session and reflashing the chip. I wouldn't know how to start a debugging session with the code already in flash... 

  • in reply to Roger Wolff
    TI__Guru**** 171729 points

    Hi,

    Roger Wolff said:
    Why would resetting the core also flush the symbols?

    You are right: the core disconnect/connect does not flush the debug symbols (I was probably carried away on the process of launching the debugger manually without the green bug button). If you don't see symbols after reconnecting, it is possible the code is in the middle of a runtime support library (where the information on the link I sent before is applicable).

    One additional tidbit: if you want to run your code from the reset vector and not from main (useful if you are debugging pre-initialization steps), you can disable the Auto-run to main option - check section 3.2 of the page below:

    http://processors.wiki.ti.com/index.php/Debug_Handbook_for_CCS

    In any case, hopefully the disconnect/connect helps your debugging.

    Regards,

    Rafael