Debian day 56: Texas Instruments Code Composer Studio

Attempt two at getting it working

The SmartShepherd devices are based around a Texas Instruments bluetooth low energy chip: the CC2640R2F. I have been using Ti's "Code Composer Studio" to build the firmware for the device. It is not my favourite tool but it does get the job done (eventually).

Previously I have upgraded my main Windows build to Code Composer Studio 10 so I know (in theory) it should work on Debian as the system is available for Ubuntu. I tried to get this working on day 1 but failed to get the setup to do anything sensible with my project. Partly because Code Composer Studio is...hard to use. Partly because all the setup is dependent on windows paths when you start a project on Windows and it's tough to find all the places you need to make changes. I mean, it's almost impossible to move a CCS project to a different directory on the same machine, so shifting it to a different operating system is a lot more work than I had planned for.

Installing Code Composer Studio 10.4

This is relatively straightforward. I downloaded the "linux single file installer" from here. The other option for Linux I assume is based on snap, so I avoided that. When you unzip the file and run the installer, I changed the install directory to /opt/ti instead of what it suggested. Up in /opt/ti/ccs40 there is a .desktop file you can add to your menu system. In my case that meant copying the entry to ~/.local/share/applications and it showed up in my menu, so I can right click the CCS icon and add it to favourites. So far so good. CCS wants to create a directory called workspace_v10, which I already had from the previously botched attempt to get it running.

Fix your projects

Eclipse (which CCS is based on) puts everything in hidden files, which really sucks. One thing I had missed from the initial windows to linux conversion was fixing the drive based paths to make them point to sensible stuff on Debian. This was a matter of hand editing the .ccsproject and .cproject files in the root of the projects. In this case, I'm building for a Ti CC2640R2F, so there are two projects required (a bluetooth stack project and the app project itself). The stack project and app projects have some truly bizarre circular dependencies, and the CCS system builds makefiles (theoretically anyway) so if you change environments it should fix all the makefiles to reflect new tool paths, new library paths and the other stuff CCS needs to build your app.

Unfortunately, the first thing CCS does when you "Rebuild project" is try to run make clean. Usually that should be unproblematic, but all the make files in the sub directories are littered with Windows paths, so the make clean fails. You have to go through all the sub directories and delete the files named subdir_rules.mk. The build system will (hopefully) regenerate these for you with your new settings and it should be OK.

One file I couldn't get to regenerate properly is "lib_linker.cmd" which stubbornly refused to get built again. I edited that by hand and the projects now build OK.

There is a newer version of the Ti compiler to deal with which meant some small code changes, and a few areas where the file names of things have capitalisation that works fine on Windows but is broken on Linux, simply renaming these to the correct capitalisation fixed that. My project now builds and I can debug it with the attached xds110 debugger. Win!

That was that. All of my development tools run on Debian and they all work well.

Final hurdle overcome

The only decision I have left is whether to continue using Windows 11 on my laptop. It's starting to bug me that I have to type "wsl" in the terminal window on VSCode and a few other irritations with WSL2 that make it obvious it isn't quite linux.

Popular posts from this blog

Tailscale ate my network (and I love it)

That magical word: Workstation

Time machine: Solaris 2.6 on QEMU