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/CCSTUDIO: v7.4.0.00015 Linux GNU GCC v6.3.1 (Linaro) Cannot set breakpoint from source window

Part Number: CCSTUDIO
Other Parts Discussed in Thread: ENERGIA, CC3100, TM4C1294NCPDT

Tool/software: Code Composer Studio

Hello,

So, fresh install of CCS v7.4.0.00015, I have an application which uses Energia's CC3100 WiFi library for a TM4C1294NCPDT target. The code compiles and loads just fine. I can set breakpoints on any lines in the main library (for example, WiFi.cpp or WiFiClient.cpp) from the source window.

The application runs properly. HOWEVER, when I try to set a breakpoint (from the source window) on code included in the library's 'utility' folder, (for example, utility/device.c, in the sl_Start() function) the breakpoint is set 'grayed-out'.

If I attempt to activate it in the "Breakpoints" window, I get the popup: "No code is associated with "../device.c", line XXX in 'path_here'".

I can open the disassembly window, and I can see the code for sl_Start() in that window. If I enable show source, I can successfully set a breakpoint from inside the 'Disassembly' window. When I do this, the 'Breakpoints' window shows "0x00005744 (sl_Start + 0xC)" instead of the usual "device.c, line 69"

Screenshot: 

Why is this, and how can I fix this? The library *does* contain mixed C and C++ code, mind.

Thanks in advance!

  • Please note, that I tried this on Windows, also a fresh install of CCS v7.4.0.00015, and everything works properly...

    Is this an indexer issue? A symbol mapping issue? I'd love to learn how and why this is; granted I don't have the depth and breadth of knowledge you guys have...

    All things considered, I will work in windows if I *haaaave* to, but I don't like it! I don't wanna!

    Let me know if you need anything from me.

    EDIT: How would one go about creating a reproducible test case for this...? Create a basic library with mixed C/C++ code?

  • Hi Phil

    Phil LaFayette10 said:
    OWEVER, when I try to set a breakpoint (from the source window) on code included in the library's 'utility' folder, (for example, utility/device.c, in the sl_Start() function) the breakpoint is set 'grayed-out'.

    Sounds like an issue where the debugger is unable to properly associate the source file with the information in the debug symbols. How did you open the device.c file? Were you prompted by the editor to browse for it or did you manually open it yourself in the editor? If you did the latter (manual option), did you open it by double-clicking on the file in the Project Explorer view, or did you do a File -> Open File' or drag&drop to the editor?

    Also, are you using any file specific option?

    A test case would also be very helpful. If you are willing to share the executable, please let me know.

    Thanks

    ki

  • Hello Ki,

    On first run (In Linux) from a fresh workspace, it prompted me to browse for the first .cpp source file in the root of the WiFi project (which I did), but CCS didn't ask for *any* of the .c files in that project's other folder, 'utility'.

    I did try this on windows -same CCS version number, fresh workspace- and CCS has prompted me to locate the first file in each directory, ie: first referenced .cpp file in 'WiFi' and the first referenced .c file in 'WiFi/utility'. In other words, it works just fine in Windows.

    Again, you guys are the experts, but to me that indicates an issue with the Linux version of CCS.

    I'll try to work out a test case for you, but it may be difficult due to company limitations. I'll keep updating :)
  • Phil LaFayette10 said:
    but CCS didn't ask for *any* of the .c files in that project's other folder, 'utility'.

    Then how was the file opened in the editor? I assume manually but which step did you take?

    Phil LaFayette10 said:
    I did try this on windows -same CCS version number, fresh workspace- and CCS has prompted me to locate the first file in each directory, ie: first referenced .cpp file in 'WiFi' and the first referenced .c file in 'WiFi/utility'. In other words, it works just fine in Windows.

    Again, you guys are the experts, but to me that indicates an issue with the Linux version of CCS.

    It does indeed sound like something is amiss on Linux. But I am not aware of any such discrepancies. It could be that the paths in the symbols for the files in the 'utility' folder are not getting handled correctly with CCS Linux. Are those files in the 'utility' folder compiled with different options than the rest of the project? And what distro of Linux are you using?

    Also, can you try opening the device.c file via the Modules view?

    http://dev.ti.com/tirex/#/?link=Development%20Tools%2FIntegrated%20Development%20Environments%2FCode%20Composer%20Studio%2FDebug%2FDocuments%2FFeature%20Overviews%2FBrowse%20loaded%20debug%20symbols%20with%20the%20Modules%20view%20(YouTube)

    Thanks

    ki

  • Interesting. I'm having issues replying; I made ya a test case. I'll switch to windows and try posting it from there.
  • It seems that when I try to choose "Insert Code, Attach Files and more..." on the forums it refuses to post... I'll try just the text of the post first...

    Edit: For TI E2E.tar.gz

    I've attached the .tar.gz of an entire workspace. The project of interest is the testcase/testcase.cpp file.

    It uses the Energia 17 core library, to pull that in I simply made a 'New Energia Sketch' from CCS, changed the compiler to GNU v6.3.1 (Linaro), and rebuilt it.

    'testcase' uses two libraries I've separated from Energia; the stock WiFi library, and a slightly modified SPI library (renamed to MHSPI).

    I believe if you create a fresh workspace, and do Import > Code Composer Projects, and check 'copy to workspace' the projects attached, it should pull just about everything.

    I do have a workspace variable set for 'TIVAWARE_ROOT' which points to my 'TivaWare_C_Series-2.1.4.178' folder.

    There are also custom compiler includes for 'energia-0101E0017/hardware/lm4f/variants/launchpad_129' and 'energia-0101E0017/hardware/lm4f/cores/lm4f'.

    The linker script is also explicitly linked to 'energia-0101E0017/hardware/lm4f/cores/lm4f/lm4fcpp_snowflake.ld'.

    To recreate, please set a breakpoint on line 55 in 'testcase.cpp', upload/run. When it hits the breakpoint, source-step with F5, and it should popup "Can't find a source file at "../WiFi.cpp".

    Browse to the file, and you'll be in status(). Keep source-stepping into init(), until the call to 'sl_Start()'

    Step into that, and you should be in sl_Start() of 'device.c'.

    Try placing a breakpoint, I tried line 102: '_SlDrvDriverCBInit();'

    Let me know if you need more.

    Edit 2: Per your first question I didn't answer: CCS just opened the right file 'utility/device.c' after I located WiFi.cpp and source-stepped into sl_Start().

    The files in the 'utility' folder are compiled with the same exact options as the rest of the project.

    I'm currently on Ubuntu 16.04 LTS.

    I can open 'device.c' via the Modules view, but it doesn't appear to change anything.

  • Hi Phil,

    Thanks for the excellent test case. It is always so helpful for us when we get a reproducible test case. I really appreciate the time you put in to provide this.

    I can reproduce the issue. I can actually reproduce the issue on both my Ubuntu 16.04 machine and my Windows 10 machine

    For some reason, the debugger is not associating the opened device.c file correctly. Can you try the following?

    Open the debug configurations dialog (Run -> Debug Configurations) from the CCS Edit perspective and select the launch configuration you are using in the left panel. Go to the 'Source' tab and explicitly add (via Add -> File System Directory) the path to ./For TI E2E/WiFi/Debug/utility. See my screenshot below. 

    Clean out any other extra paths you may have.

    Try the test case again and let me know if you can set breakpoints in device.c

    Thanks

    ki

  • Ki-Soo Lee said:

    Thanks for the excellent test case. It is always so helpful for us when we get a reproducible test case. I really appreciate the time you put in to provide this.

    Of course! It's what I'd want if I were in your shoes. :)

    Okay, so I tried two permutations of your suggestion.

    First, I went to Run > Debug Configurations > Source (for testcase) and removed the path that was created the first time CCS asked me to locate source files, "..WiFi.cpp blahblahblah"

    I then tried adding the path:

    "/home/captain/workspaces/tie2e/WiFi/Debug/utility"

    applied changes, then debugged. First source-step into WiFi.status() and CCS pops up "Can't find a source file at "../WiFi.cpp" so I browsed/selected it. Stepped through to "device.c" and still couldn't set a breakpoint.

    It ain't my first time around the block, and I realized that your screenshot was different from the path you quoted. (Super common oversight!)

    So, I went back, cleared the non-default paths, and added the path:

    "/home/captain/workspaces/tie2e/WiFi/utility" (no Debug/utility)

    Applied changes, debugged, and it works!

    So, we have a workaround!

    In the meantime, will this provide enough info to get a fix in the next CCS release?

    Also, thanks!

  • Phil LaFayette10 said:
    It ain't my first time around the block, and I realized that your screenshot was different from the path you quoted. (Super common oversight!)

    argh... sorry about that! Thanks for catching that. 

    Phil LaFayette10 said:
    In the meantime, will this provide enough info to get a fix in the next CCS release?

    Yes, we certainly have a solid test case (thanks again!) for the engineers to investigate further. Hopefully we can get a fix for this in the next release.

    Thanks

    ki

  • Awesome, Thanks again Ki!
  • I filed a bug for this. Tracking ID: CCDSK-3021