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.

sitara AM437x Debug using usb cable.

Hi ,

we are using AM437 IDK and  using the USB cable provided with the IDK to debug the board. we tried to debug some sample programs like toggle led and the sample program is working.

but if we tried to stop the debugging session and try to debug again, the debug control is not going to main and is getting stuck.

So to debug again, we need to remove the power supply and connect the board again.

what is causing this issue?

 

 

  • Hi,

    What debug software are you using? Which version?
  • Hi,
    The board is connected to the PC using the USB cable provided with IDK.
    We are using the same for debugging.
    When the boar is powered on and USB cable is connected to the PC, it is detected as XDS100V2 USB debug probe.

  • Hi
    The board is connected to the PC using the USB cable provided with IDK.
    We are using the same for debugging.
    When the boar is powered on and USB cable is connected to the PC, it is detected as XDS100V2 USB debug probe.
  • What is the PC software? CCS? Which version?
  • Windows CCS 6.1.0

  • I will move this to the CCS forum, where you may get better advice.
  • Hi,

    jinu jacob said:
    but if we tried to stop the debugging session and try to debug again, the debug control is not going to main and is getting stuck.


    What are you exactly doing here?

    Regards,
    Vinesh

  • Hi Vinesh,

    We are trying to debug the AM437x IDK board example project.

    To do this, we used the USB cable provided with IDK and it is detected as XDS100V2 USB debug probe.

    We used CCS6 to open the Toggle LED example project.

    When  we debug the program for  1st time , it is running properly and the control is coming inside main() as shown below.

     

    and if we tried to relaunch the debugging session again, we were not seeing any options like stepping the program etc,

    it is showing as follows.and the code control is not coming inside main()

    To debug again, at present we are switching off the board and turning it on and also closing the CCS and opening it again

     

  • To restart, you need to do a "System Reset"-> Execute GEL scripts -> Load program.

    Regards,
    Vinesh
  • We had similar issues with CCS 6.0, I haven't tried CCS 6.1 and don't know if it's been fixed.  See my post in https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/401837

    Key things we learned:

    * "System Reset" in CCS was broken for this chip, it somehow confused the emulation logic.  (TI have never fully acknowledged this to us, but it never worked properly, and the workaround below was the best they could suggest)

    * To restart a program, we still had to "disconnect" in debugger, physically press the reset switch on the EVM board, then "reconnect" debugger.  If you did this carefully, it did restart debugging reliably.

    * fixes to GEL files helped make the debugger start faster and more reliably after a connect, these may have been folded in CCS 6.1.

    I'd be happy to learn that CCS was fixed, but it sounds like it isn't.

  • Hi Gordon,

    Thanks for the reply. To restart the program again, as you mentioned above, i have to  "disconnect" in debugger, physically press the reset switch on the EVM board, then "reconnect" debugger.

    I tried using the GPIO LED toggling example. In this, the Toggling is done inside a infinite while loop.

    if i start a debug session, then it toggles gpio eventhough we did suspend or Terminate from debug window.

    Is this also because of the same issue mentioned above?

  • Hi Vinesh,
    After doing the System reset also, if i tried to start a debugging session again,it is showing the following messages.


    "
    Error connecting to the target:
    (Error -1141 @ 0x3D58)
    Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK).
    ( Emulation package 6.0.14.0)

    "

    The working solution is to terminate the debug session and a power cycle to board.
  • Jinu,

    Yes, I think this is the same thing I saw.

    Vinesh, I have no idea why your GPIO application doesn't stop. I did have some issues with breakpoints being unreliable, but can't remember what the circumstances were.

    I highly recommend the patch to the GEL files to force the thumb state register on reset (see my post link earlier) - this seemed to improve reliability of the debugger as well.