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)

Image
No matter where you go, there you are If you're like me, you travel occasionally. Access to your office from home, or from an airport lounge, or from a hotel room is paramount to being productive for most of us now. While I had a fairly simple Tailscale setup that got me into my test machines in the office, what I really wanted was to integrate my AWS production VPC into that system. It's surprisingly simple. Tailscale AWS instructions What do you want to do that for? In the "before tailscale" times, if I needed to test against the production AWS resources or connect dBeaver for database maintenance, I would edit the security group to add my IP address, do my testing, edit the security group to remove myself. This is as error prone as it sounds. I quite often forgot to remove my IP address from the allowed addresses, a major potential security risk when you are travelling. Tailscale has an extremely nifty way to get around it: if you run up a small ec2 ins
Read more

Stupid stunts with WSL2 , Python3 and AWS ECS

Image
Hand rolled CMS system gets a previewer The ongoing process of updating the help system on the SmartShepherd inspired two new features: editing of the html in a temporary location and a small web server to check your work before pushing it to production. The surprise? That GitHub desktop will show you a side-by-side view if you change an image file. Can't believe I didn't notice that before. Can you hold my camel for me? Sometimes I get so far down a dead end I don't realise how many issues could be sorted simply by re-thinking something. The initial deployment of the SmartShepherd web server was to an Elastic Beanstalk setup on AWS, mostly because I had no idea what I was doing. Elastic Beanstalk isn't really one product, it's more of an elaborate script that creates systems for you. In my case, it was spinning up a small Windows EC2 instance, installing the .NET Core website and auto-configuring a load balancer to point to that instance. I mean, it's
Read more

Time machine: Solaris 2.6 on QEMU

Image
You can never go home A big chunk of my professional career in the 1990s was spent with a Sparcstation on my desk. Before that the 68000 Sun2 and Sun3 floated past my sticky fingers but the Sparc machines quickly superseded those. I don't remember too much about which ones: pretty sure there was at least one IPX, one Sparcstation 5, a Sparcstation 10 and then the last one was most likely an Ultra 1 or maybe even an Ultra 5. It was a long time ago. Every now and again I think about how productive those machines were and do a little Ebay digging on how much one would be worth to have around. Except I don't have the room for more machines and the idea of trying to revive 25 year old hardware from that era is well beyond my electronic capabilities. Never fear, QEMU is here. Following these excellent instructions from Adafruit , you too can install Solaris 2.6 and have your very own emulated machine. Note that there is one instruction in there I am not sure you need. A
Read more