• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 55 subscribers
  • Views 1792 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.

CCS sometimes has wrong line numbers when debugging imported Energia sketches

Rudolph Raab
Intellectual 760 points
Other Parts Discussed in Thread: ENERGIA, EK-TM4C1294XL

When I press the pause button on running code in a CSS debug session for an imported Energia sketch, it sometimes references the line number of the next code line after the one it's actually stopped at. As far as I can tell, this only occurs with a program which has hung somewhere (e.g. an infinite loop). 

I've only tested this with a EK-TM4C1294XL launchpad, because that's the only hardware I have. I'm using Energia 0101E0012. It doesn't appear to be a compiler issue because I've tried replacing Energia's GCC 4.7.3 with my own GCC 4.8.4, with no change in behavior. 

Has anyone else observed this?

P.S. I'm using CCSv6.0.1.00040, on Windows 7 x64. 

  • 0
    TI__Guru**** 162305 points

    Rudolph,

    I am trying to reproduce this.  I am using the blink example as it has a loop in it.  Are you seeing a mismatch between the items in red below or a mismatch between the items in red and where the PC is actually shown?  Or a mismatch between the items in red, the location of the PC arrow and the actual location of the PC?

  • 0 in reply to JohnS
    TI__Guru**** 162305 points

    One thing to take a look at is the Disassembly View.  That will show both the assembly statement CCS has halted at as well as the source line that it feels it is associated with.  I have seen some strange things where because of pipelining part of the next instruction (fetch) has started and hence the source assocation shows that the next line of source has been executed when really you are still on the previous line.

  • 0
    Prodigy 10 points

    I had the same issue with other project and the problem was in incomplete line break. It's is visible only in a hex editor.

    Can you upload a zipped directory of the project to follow the issue?

    Regards.

  • 0 in reply to jose antonio migens
    Intellectual 760 points

    I've attached a simple zipped project that exploits Energia's broken readBytesUntil to hang reliably-- send it anything on serial at all and it'll hang at the same place. See also my attached screenshots of the debugger to see what I mean-- the line numbers agree with each other but are both wrong. 

    Also, I believe the last shot shows that line 362 has not yet been executed-- otherwise the mouse-over view of cChar would show its current value. Additionally, the disassembly appears to show the wrong line. 

    Don't set any breakpoints in this project; just send something and then pause. If you breakpoint inside HardwareSerial.cpp and single-step, it won't have any issues and the line numbers will be correct. The issues only happen when something goes wrong. 

    1261.HangingSerial.zip

    2158.CCS_Debug_Issues.zip

  • 0 in reply to Rudolph Raab
    TI__Guru**** 162305 points

    The "should_be_239" and "should_be_35" captures look like a bug.  The "should_be_362" looks right given the instruction that is shown to be executing in the disassembly view.

    Basically for anything in a previous stack frame it looks like it is off by one.  

    I will reproduce this and file a bug against the debugger in CCS.

    John

  • 0 in reply to JohnS
    Intellectual 760 points

    Any luck reproducing the issue?

  • 0 in reply to Rudolph Raab
    TI__Guru**** 162305 points

    Yes I was able to reproduce and have a defect filed.  The tracking number is: SDSCM00050833

    I filed on Friday so I don't think the development team has had a chance to look at it yet.

    Regards,

    John

  • 0 in reply to JohnS
    TI__Guru**** 162305 points

    We have been having a lot of discussion with the debugger team on this one after filing the defect.

    What you are seeing in CCS is intentional.  Basically it is showing where it is going to return to vs where it entered the next frame.  The reason for this is that when optimization is on you may have a() calling b() calling c() but the call frame is setup so that c() returns directly to a().

    Anyway it doesn't look as straight forward as we thought.  Some compilers have extra debug info generated that helps figure things.  

    We are still talking about this one but I thought I should give you an update.

    John