CCS debugger launches the wrong project

I split this out into a new thread because the other thread you posted to was over 3 years old and it is easy for posts to get lost in very old threads.

Could you provide a little more detail on how your projects are set up? Or even better, a simple reproducible test case?

So your four projects have several source files that are common among all projects. Are these source files in some common source folder that is then linked to all the projects, or is it "added" to (physically inside) one of the projects and linked to the other three projects? The former method is generally better practice to avoid issues during debugging.

Thank you for noticing my post despite being in an old thread.

As I described, we are writing one software system that can execute on several different boards and TM4C variants, including our own design as well as TI EK-TM4C129EXL and EK-TM4C123GXL LaunchPads.

This works out well because almost all of our code is portable among the different hardware configurations, and we have a single global Configuration.h include that uses compile-time conditionals (#ifdef/#endif) to take care of the hardware mappings. We use TivaWare and call the MAP_ functions so as to use the functions in ROM when available and link flash versions into our code otherwise.

So the main directory of our software code (let's just call that directory "Software" for simplicity) contains only the .c and .h source code files that are independent of the specific board and TM4C variant, and that's nearly all of our source code.

The only other thing in this "Software" directory is one subdirectory for each board, so there is a directory called EK-TM4C129EXL, another directory called EK-TM4C123GXL, and directories for our boards.

Each of these directories contains a CCSv7 project that builds the software for that specific board. So for example the EK-TM4C123GXL directory contains the following:

• .launches
• .settings
• Debug - Build files for Debug build configuration with TI toolchain
• Debug__GNU - Build files for Debug build configuration with GCC toolchain
• Release - Build files for Release build configuration with TI toolchain
• Release__GNU - Build files for Release build configuration with GCC toolchain
• targetConfigs
• .ccsproject
• .cproject
• .project
• tm4c123gh6pm.cmd - Linker script for TI toolchain
• tm4c123gh6pm_startup_ccs.c - C startup file for TI toolchain
• tm4c123gh6pm.lds - Linker script for GCC toolchain
• tm4c123gh6pm_startup_ccs_gcc.c - C startup file for GCC toolchain

The EK-TM4C129EXL directory contains the similar things for its respective board, and so on.

So what I have described here is separate CCSv7 projects:

Each is in its own folder named for the board it will run on.

All these folders are inside the same parent folder

That same parent folder is where all the common source code files are located

All of these projects are displayed in Project Explorer, as they have all been imported into the workspace. The workspace folder does NOT contain our projects. The projects are linked, not copied into the workspace folder. This is the case because we keep our projects, but not our workspaces, in version control and work in a separate working directory.

To answer your question, that parent directory (the one with the source code and subdirectories for each board) is NOT added to the projects as a linked resource, because that would probably confuse CCSv7 when it recurses into subdirectories, as it would start finding all the different projects. Again, that's the directory that is not linked. Instead, all the source code files have to be added to each project as a link to the original file. They are linked relative to the ${PROJECT_LOC} variable, which ends up looking like <locationURI>PARENT-1-PROJECT_LOC/SourceCodeFile.c</locationURI> in the .project file.

The code compiles properly and runs correctly in all build configurations, with either TI or GCC toolchains, on all the boards. The issue is the starting a debug session seems to switch to the wrong project just before it programs the board, unless we make sure that all projects, except the one we want to debug, are "closed" in project explorer.

I hope this description is more clear and helps to pinpoint the issue.

Thank you for providing details. I tried to create a simple project environment that mirrors yours but so far have not been able to reproduce the issue with the debug session opening the wrong project. Perhaps I am missing some nuance that triggers the issue. 

Would you be able to share your projects (and the main "Software" directory with the common source files) to help us reproduce the problem? I would imagine that even 2 out of the 4 projects should do if that is sufficient to demonstrate the problem.

Hi AartiG,

Thanks for looking into this.

I tried (and so far failed) to reproduce the issue by creating a new workspace with two new "test" projects. It was based on the same idea and the same layout as our real work, but is a contrived example that only blinks a LED on the board. The projects in the subdirectories are for EK-TM4C129EXL and EK-TM4C123GXL since TI has access to such boards. :-)

Unfortunately I have not (yet) been able to reproduce the issue with this "test" workspace and projects, but because this did occur with our real project, I agree with your thoughts that there must be some nuance in our projects.

I think the nuance could be this: After we created our first project and configured everything in it, we created each remaining project by copying that original project. I think we made some copies in CCSv7 Project Explorer by copying and pasting the project; but I think we also used our version control software (SVN) to make some copies. I need to test this further to know for sure, but if there is some sort of UUID/GUID or other "unique project ID" embedded somewhere in the project files that CCS knows how to update when making a copy, then that would certainly cause issues when we copied the project using other means outside of CCS. When I tried to recreate the scenario by creating my new projects, just as you did, they did not suffer from this problem. At least this is my reasoning right now, and I have not tested this yet.

I will try to create a workspace and projects to reproduce the issue by duplicating our real work and then removing anything irrelevant... That will take some time since I will have to test that it actually reproduces it!! I'll let you know what I find.

Thank you for the response and for trying to recreate a test scenario. Please do take your time and whenever you have something to send us, we will be glad to investigate further.

twelve12pm said:

I will try to create a workspace and projects to reproduce the issue by duplicating our real work and then removing anything irrelevant... That will take some time since I will have to test that it actually reproduces it!! I'll let you know what I find.

I'm not sure if you've been able to create a reproducible scenario yet, but I wanted to let you know that I plan to close out this thread for the time being. However, please feel free to come back here and post an update when you have a reproducible test case, and we will be glad to reopen and re-investigate the issue.

I haven't yet created a reproducible scenario for you, but I will say that every so often, something "weird" happens and I'm never quite sure if it's something I've done or a bug. For example sometimes the active project in the workspace changes, sometimes the Clean dialog doesn't have the same check marks as before... But as these things happen in the midst of heavy-duty work and I'm switching back and forth between CCS and other applications, I can't tell you exactly what the sequence of events is.

If I come up with something definitive, I'll let you know.

Thanks for your help as always.