CCSv5 Breakpoint Problem

Hi Justin,

Justin said:

I'm using CCS v5.2.1.00018 on an OMAP3 processor- I cannot set breakpoints inside a function, but I can set breakpoints at the entry point of the function (by creating the breakpoint manually) and step once inside. 

For the breakpoint you can set at the entry point, are you able to set them from the editor? You mention you are setting it manually. DO you mean you set it on a specific address in the breakpoint view?

Justin said:

If I try to set a breakpoint inside the function it gives the "No code is associated with" error and disables it.  This also seems to break "run to cursor" as well.  I'm using a Blackhawk BH-USB-560v2 as the debugger.  The dissassembler matches the C code and I can set a hardware breakpoint in the dissassembler, but it's a tedious process to find the right spot to break in assembly.

The compiler flags aren't the issue since I can use the same image with RealView Ice and breakpoints work fine everywhere.

I was going to suggest that you may have built your application with some optimization enabled but given that mixed mode in the disassembler is correlating source with assembly correctly and you mentioned that the compiler flags are not an issue, sounds like you optimization or debug symbols are not an issue.

How are you debugging this project? Do you have the project open in the workspace and sued the "Debug" button or did you do a project-less debug session and load your application manually?

Thanks

ki

Ki-Soo Lee said:

For the breakpoint you can set at the entry point, are you able to set them from the editor? You mention you are setting it manually. DO you mean you set it on a specific address in the breakpoint view?

I have to click on the "New Breakpoint" button and type the function name I want to break at.  I can't double click the line - it just automatically disables the breakpoint if I do that. 

Ki-Soo Lee said:

I was going to suggest that you may have built your application with some optimization enabled but given that mixed mode in the disassembler is correlating source with assembly correctly and you mentioned that the compiler flags are not an issue, sounds like you optimization or debug symbols are not an issue.

I'm looking into the compiler flags now, the only reason I say it's not an issue is because another IDE and debugger (RealView ICE) works just fine, which tells me all the needed symbolic information is in the image.

Ki-Soo Lee said:

How are you debugging this project? Do you have the project open in the workspace and sued the "Debug" button or did you do a project-less debug session and load your application manually?

I'm doing a project-less debug session and I load the image manually (Run->Load Program).

Another odd thing is I can't watch static (file level) variables, even if I break in a function that is using that variable.

Thanks,

Justin said:

I'm doing a project-less debug session and I load the image manually (Run->Load Program).

Ok I figured as much. Sounds like the debugger is not correlating the source file you have open in the editor with the loaded symbols.

Did you use a CCS project to build your application or did you build outside of CCS, perhaps even using non-ti build tools?

Correct, we're building outside of CCS with an ARM compiler.

Any ideas on a fix or work around?

And how are you correlating the source files with the debugger? Did you create a CCS dummy project? Or did you add them to debug source lookup paths or simply browse to the file when instructed to by the debugger?

I don't have a dummy project, I just load the AXF file to the unit and load symbols from the same file.  Once I create a breakpoint by typing the function name manually, it breaks and opens the C file and dissassembler.  I'm guessing the AXF file has some reference to where the C files are located (relative or absolute paths) and it's finding them OK automatically?

Once it's running I can open the modules section, drop down the functions and files and browse the project with no problems (other than not being able to add break points).

Justin said:

I'm guessing the AXF file has some reference to where the C files are located (relative or absolute paths) and it's finding them OK automatically?

Yes the AXF file has the dwarf debug symbols for the executable like the location of the source files (should be relative path) so if the source files are still in their original location, the debugger should be able to find the files. I'm pretty sure there is some issue with a path mismatch between the breakpoint manager and the debugger. I've seen this before, especially with executables build outside the CCS build system.

Justin said:

Once it's running I can open the modules section, drop down the functions and files and browse the project with no problems (other than not being able to add break points).

Are you referring to the modules view (View -> Modules)? That was going to be my next suggestion. Could you open the source files from the modules view and try to set a breakpoint (if you did not so already). Also in the Modules view, when you click on a source files, what does it say for the relative and compilation paths?

Ok, so I figured something out here - it seems that if the C file is in the same folder as the AXF then I can set breakpoints anywhere.  If the C file is in a subfolder then I have to break by manually typing the function name.

The odd thing is with the View -> Modules I can find the files and functions in subfolders, and double click them to open the file, I just can't break inside the function like I can for C files in the root.

Any ideas?  Thanks.

Hi Justin,

I think I came around a problem that seems pretty closely related to yours and your posting helped me to understand better what is happening (thanks for it!):

- we are building a C language project not from CCS but we are using a (more transparent) makefile toolchain

- we want to use CCS V5.2 for debugging purposes only (to see whether the generated binary file *.bin/*.out/*.hex ...is behaving the way we want it to)

- even if we have a corresponding CCS project (that seems to find all source files), we need to proceed as you describe it:

1. set a breakpoint to eg. a function call

2. if we want to step into the function or set a breakpoint inside, we obtain an error message that seems to indicate that CCS cannot resolve the source file

(>>Can't find a source file at "example.c". Locate the file or edit the source lookup path to include its location.<<)

3. after explicitly locating the c-file (by pushing the button "Locate file ..." that CCS offers with the message above), it is possible to step inside and set breakpoints and so on.

The proceeding is a bit laborious ... but one can make do with it.

The problem seems to be that from a user's point of view, one would expect that CCS is "automatically" able to locate those C-files of which it "knows" that they are part of the project - but this does not seem to be the case.

I suppose that one will not tend to come accross this problem it he is using the CCS build toolchain (however I did not test it)

Regards

Christian