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.

Jumping to wrong place from breakpoint



Hello,

I am trying to debug a USB application and when I set a breakpoint I jump backwards to an incorrect line in the firmware application.  Does anyone know why this would happen?  I'm seeing sporadic behavior (jumping to what looks like random places) when using "step into" or "step over" at a break point.  An example can be found in the attached screenshot.  I try to "step into" the function call "USBDBulkInit" but instead jump backwards as shown by the arrow to "USBStackModeSet".  If I continue clicking jump into I eventually get into the function call where the breakpoint is set, but once in that call I just experience more sporadic behavior.

Any help is greatly appreciated.  

  • Hello,

    Does anyone know why this would happen?

    The most common cause is that you are trying to debug optimized code.

    Please see the below article for more details:

    https://dev.ti.com/tirex/explore/node?node=A__AEm7LJjS34iFPa5fpT7ttQ__ccs_devtools__FUz-xrs__LATEST

    Thanks

    ki

  • This sounds reasonable but two quick questions.

    1. I'm using the usb driver library and I noticed when I change the source code in the root tivaware driver library folder for USB code the changes don't take affect.  I'm assuming this is because the code isn't compiled but linked in as I can copy and paste the lib file of interest, change the include in my main.c and rebuild with the modification and then I see it.  So - is this an issue?  I can remove all optimizations for "my" source code, but not for the tivaware usb driver library.

    2. Do I need to recompile the usb driver library myself to remove any optimizations that may have been on during compile time or should CCS be re-compiling tivaware usb driver lib every time and I'm missing something?

  • If you are trying to step through code from a library linked in to you e main application, then you would need to rebuild the library with optimization disabled for full debug visibility.

    CCS will not be recompiling the usb driver library unless it was added as a dependent project. Even then, any build settings applied to your main projects would not propagate to the dependant project anyway.

  • Hi Ki,

    Thank you for the response it looks like you are correct.  In working on this project, I've recompiled the usblib project and will be testing it to see if I can step through the code with optimizations off now.  I did however notice something that led to a couple more quick questions.

    1. When I open the usblib project to recompile after turning off optimizaitons I notice I'm unable to see the header files in the device folder.  Is this expected?  When it is "included" in my custom project and I go to includes folder and browse to this usb device folder in my CCS project navigator I can see the header files.

    2. What is the typical approach for developing/debugging code with optimizations?  I haven't done a lot of this but I imagine a lot of firmware engineers have to work with some degree of optimizations on - how do they approach debug in this situation?

  • 1. When I open the usblib project to recompile after turning off optimizaitons I notice I'm unable to see the header files in the device folder.  Is this expected?  When it is "included" in my custom project and I go to includes folder and browse to this usb device folder in my CCS project navigator I can see the header files.

    I assume you are referring to usblib from TivaWare. The "Includes" folder in Project Explorer should show all the include search paths in the project build settings. If you expand the folders, it would list all the contents for the folder. The below is the expected behavior.

    2. What is the typical approach for developing/debugging code with optimizations?  I haven't done a lot of this but I imagine a lot of firmware engineers have to work with some degree of optimizations on - how do they approach debug in this situation?

    It is actually discussed in the article I mentioned earlier under "What to Do".

    https://dev.ti.com/tirex/explore/node?node=A__AEm7LJjS34iFPa5fpT7ttQ__ccs_devtools__FUz-xrs__LATEST

    Thanks

    ki

  • Thank you for re-linking that.  The article is great and I'll be reviewing some others in that knowledge base.  very helpful!

    My first question was really just asking why does my usb device test project (normal TM4C project) show the header files and the usblib (you are correct - from Tivaware) only show the .c files?  See screenshots below.  I figure I'm missing something when you import a library like Tivaware usblib.

  • My first question was really just asking why does my usb device test project (normal TM4C project) show the header files and the usblib (you are correct - from Tivaware) only show the .c files? 

    Because in your first screenshot, the Includes folder is showing the contents of all files in the directory.

    In your second screenshot, you are not looking inside the Includes folder but instead the <PROJECT FOLDER>/device. That folder is empty. In Project Explorer you can see a bunch of LINKED FILES. Those files are not physically inside that folder but instead the project has references to the actual location outside the project folder.

    You can see that by looking at the file properties that it is in the root TivaWare directory and not the project folder.

    Only the *.c files are linked, not the header files.

    For more information on linked files, please see:

    https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#adding-or-linking-source-files-to-project

    Thanks

    ki

  • EDIT: I altered the screenshot location in my post above for better clarity

  • Thank you Ki!  You were a huge help and I'm now up and running modifying the usblib as needed!

    Thank you!