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.

CCS debugger hangs on stepping over specific instruction

Other Parts Discussed in Thread: AM3359

Hi,

I'm using CCS5.5 and XDS100v2 to debug code on AM3359 chip. Generally, everything works fine, I load code, run it, put breakpoints, step into and over, etc.

However, I bumped into a problem. My debugger hangs and stops responding when I stop before and try stepping over a very specific instruction at a very specific address. Given that this is a simple ADD instruction, I totally don't understand why does this happen:

The above screenshot is AFTER I clicked "Assembly Step Into" on the ADD instruction. But it did not perform the step. Clicking again does not help.

I attempted the following without success:

  1. Disabling IRQs by altering the CPSR from the debugger a few instructions before.
  2. Power cycle, restart CCS and PC.
  3. Replace the JTAG emulator by another piece.
  4. Replace the development board (the one having AM3359).
  5. Putting a breakpoint on the STR instruction and clicking "Resume" (the core is still shown in Suspended state but all the step buttons are grayed out.

However, putting a breakpoint somewhere further, outside of the function in question and clicking "Resume" does work! The debugger runs and stops on the new breakpoint.

Please advise!

Regards,
Vasili

  • Vasili,

    Without code that reproduces that behaviour it is difficult to pinpoint an exact root cause, but my first (wild) guess would be memory latency with the STMFD opcode. The fact it is halted at the ADD is probably because it is waiting for R13 to be updated from the previous opcode. I have seen that happen sometimes.

    Apart from that, I can see you thoroughly went through steps that I would also have tried myself. I can't explain step 5, but I will try to think about other possibilities and reply here.

    Regards,

    Rafael

  • Hi Rafael,

    I've successfully reproduced the problem on the ICE development board. Please approve me as "friend" so that I can send you an ELF file.

    There is also another problematic behaviour that I encounter sometimes - the debugger fails to halt at all. I suspect these two problems are connected.

    This is a major issue really complicating our development.

    Best regards,
    Vasili

  • Hi Rafael,

    Any news on this issue following the code I sent you in private?

    Sorry for being so persistent, but we are continuing having various problems with the debugger, both on development kits and our hardware.

    The most common problem is that the debugger just fails to pause execution until reset is issued. Obviously, this is a big problem which greatly complicates our work.

    Regards,
    Vasili

  • Vasili,

    I am very sorry for the delay in your reply. We were able to find this issue is related to the way the CCS debugger handles the stack when using GCC projects and we just released a patch for Windows. I will send you privately.

    Regards,

    Rafael

  • Rafael,

    I just installed the patch and verified it solves the problem. I'll try using it and hope it solves the other problems we experienced with the debugger as well.

    Many thanks,
    Vasili

  • Hi Rafael,

    Is the issue in question supposed to be fixed in current CCSv6 beta? I tried CCSv6 (due to some other problems with CCSv5) and bumped into a similar issue of failing to pause the debugger.

    Regards,
    Vasili

  • Vasili,

    I wouldn't expect so. This issue was found/fixed too close to the release date of the current v6ß.

    Regards,

    Rafael

  • 1. Just to be sure - Can the issue we are talking about be responsible for debugger failure to halt execution? (The original problem I reported was debugger failure to step).

    2. So far I did not encounter debugger failures to halt using the fix you sent for CCSv5.

    3. However, there are many other problems with CCSv5 (for example it shows all local variables wrong for us).

    4. CCSv6 seems to fix many of the problems, but presents the problem with debugger halts.

    If it is indeed the same issue, how soon can we expect an updated beta release including the fix?

  • Greetings Rafael:

    I know this thread has been marked as SOLVED, but I am seeing a similar situation trying to use an XDS100v2 with the BeagleBone Black, and the StarterWare Demo program.  The DEBUG mode is very unstable. When debugging DemoMain often times the debugger will seem to go off into the weeds when performing a Run-to-Line or single stepping.  Sometimes I get a dialog with the message GEL Expression:GEL_Go(hex_address). I have tried dropping the JTAG clock to a lower frequency without success.  I have also trired a second XDS100v2 and several BBB modules. 

    I am using the BeagleBone Black GEL file that is provided with CCS.

    When will the above mentioned patch be pushed out to the general public? How can I determine if I already have this patch installed?

    Respectfully,

    Dave

  • Hi Dave,

    Are you using the GCC compiler?

    Best,
    Vasili

  • Greetings Vasili:

    Currently, I am using the CCSv5.5.0.00077 IDE with the TI v5.1.1 compiler to compile & debug the StarterWare examples. 

    There is internal pressure to move to a generic Eclipse IDE with the gnueabihf cross compiler.  I have so far resisted this pressure, but at this point I am willing to try anything to get a fully functional debug environment.

    Respectfully,
    Dave

  • Hi Dave,

    I recommend you open a separate thread for your problem. As Rafael stated above, the patch mentioned here deals with "the way the CCS debugger handles the stack when using GCC projects". So I doubt it can fix your problem.

    Best,
    Vasili