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 doesn't behave

I have set a break point on a function call but once I break I can't single step. It wont step into the function or step over the function. If I remove the break point I still can't single step. Even in the disassembly it just sits on the same MOVS instruction. If I remove the break point and and do a core reset it still breaks on the same point. The only way to truly remove the break point is to cycle power on the processor.


I've also notice single stepping will jump around in unexpected ways. I'll break on something where the next statement should always be the next one executed and a single step will bring it up several lines.

Is there a trick to the debugger? It seems buggy to me.

  • I've seen the unexpected jumping happening when the code loaded to the processor either isn't compiled from 1:1 the same sources the debugger has access to, or has been compiled without debug symbols. For example, if you are stepping through a driverlib function, this could easily happen. I usually just "step over" any driverlib function calls.

    Breakpoints sticking / not being able to set breakpoints is something I've also come across, but haven't yet been able to isolate the reason why it happens. Usually when I see that kind of behaviour, I shut down CCS (and any serial terminal emulators connected to the virtual serial port), un/replug the devices and "start over".

  • Hello Ryan, Veikko,

    This is a behavior when the optimization level are set. If you compile the driverlib and project with optimizations off the code would behave as expected. of course with optimizations off, the code will be larger in size that with optimizations on (unless the code has been written with direct memory operations or asm)

    Regards
    Amit
  • Oh that's right. I forgot all about the evils of optimization when debugging. I generally just turn them off but I haven't created a new project from scratch in over a year.
  • Hello Ryan

    Does the issue still occurs with the optimizations off for both the main code and the pre compiled driverlib.lib?

    Regards
    Amit
  • It's a little better. I was able to step into a driverlib function but now its stuck on the same function. Even if I disable the breakpoint I can't even continue.
  • Hello Ryan

    What function is this? Is it a while loop waiting for a HW register bit to be set or clear. If that is the case then it could be possible that the transaction is not happening due to some other reason causing the code execution to be stuck?

    Regards
    Amit
  • Its part of the grlib. GrStringDraw()

    There is nothing preventing it from entering the function.
  • It looks to me like the debugger does not actually know where it's at, even in the disassembler. I just watched the debugger sit on a line of code but I could see by watching the memory it was executing the line above it. In the disassembler it just sat on the same mov instruction.

    It's also not clearing breakpoints. I can disable it but it still hits it until I cycle power on the processor.
  • Hello Ryan,

    I would suggest recompiling the grlib driver library function as well

    Regards
    Amit
  • I've been recompiling the grlib all along, it's where I'm writing half my code.

  • Hello Ryan

    What part of the function GrStringDraw does it get stuck in?

    Regards
    Amit
  • Ryan Lush67904 said:
    I've also notice single stepping will jump around in unexpected ways. I'll break on something where the next statement should always be the next one executed and a single step will bring it up several lines.

     Hi Ryan, this issue is known and new release promised fix it. If you search on CCS forum a thread address this problem.

     When you encounter it you must do a hardware reset, software reset then remove breakpoint, step over then reenable BP if you still need have active, no chanche to disable, it still remain there.

     If this workaround doesn't work for you please do an error submit too.

     

  • Roberto Romano said:
    ...this issue is known and new release promised fix it.   If this workaround doesn't work for you... 

    One must ask - if a "workaround" does not work - does it qualify as a, "Workaround?"

    Further - Amit hasn't mentioned this, "workaround" anywhere (this thread).   Might that indicate that (he) believes it is fixed - and that o.p. is using an older version of grlib?

  • cb1_mobile said:

    One must ask - if a "workaround" does not work - does it qualify as a, "Workaround?"

     Hi CB1, I find you particularly <pedantic mode> as lint do when you ask to do that...

     CCS is multiplatform and I am using on Linux, I wish also be on a better platform than PC but here we are and old time elapsed...

     On Linux I experience this and other known issue, poster has not specified OS is using nor version of CCS, specific problem exists platform/oses on so I cannot be specific.

     I assure you I don't suffer "same drive" installation issue but all I need install from WINE or in VBOX suffer this issue too. So I lknow from early day I try'd CCS on VBOX XP but I am proud stay away frrom M$ add on ;)

     "c:\xxx" file not found on my platform are programming error on M$ issue ;)

     SO issue touch win 7 8 8,1 and so on are out of my control, but sometimes I must (SIGH) use some win only utilities and I have to discover platform specific issue.

     I assure also when I left IAR in favour of CCS Linux based all TROUBLES I suffered on debug MSP based code where mitigated a lot. This is true when some impulsive device is close to pc.

  • It happens everywhere. Not the same spot in the grlib. You can pretty much rest assured any break point I set wont work properly more than 50% of the time. Currently I set a break point at the first if statement in the GrFontGlyphRender function and it just gets stuck there.


    If I start the debug session over and break at the same point, the first single step takes me back up to the opening brace of the function. The second single step takes me back to the if statement. The third single step takes me back to the opening brace. The forth single step takes me back to the if statement and the fifth single step takes me to the next statement after the false if statement.

    I'm not breaking on loops ever. And as always I can see in the dissassembler the processor isn't doing anything. My guess is the processor is doing something, CCS just doesn't have a clue what's going on...


    I'm using Version: 6.0.1.00040 on Windows 7 64bit. I was much happier with CCS 5.2 but I had to upgrade when I switched to the Tiva.

  • Hello Ryan,

    I have used CCSv5.5 and CCSv6.0 on Tiva and so far debug with no optimizations always make the code work as expected. However with the addition of grlib is something I have never tried, but most of the examples that I have worked on with grlib during debug work as expected.

    Does the PC change even when the processor is not doing anything? If it changes then indeed it may be a bug in CCSv6 with specifics beyond the Tiva Forum...

    Regards
    Amit