Code Composer Studio v7

Code Composer Studio (CCS) is an excellent free IDE from Texas Instruments for TI processors.  CCS is based on Eclipse and TI recently released CCS v7 in December 2016 based on Eclipse 4.6 with CDT 9.0 and JRE 8. This is reported to be the first CCS release both free of charge and without limitations for all devices and debug probes, although I started using CCS just after v6 was released and it was free then, including the debug probe for the MSP432 and without code limitations when compiling using gcc (included). 

I had been put off Eclipse by its complexity several years ago when settling on an IDE for web app development (at the time I selected NetBeans, and still like its simple elegance), but the MSP432 was the processor of choice for a project and that meant using CCS/Eclipse. Although I was initially apprehensive, TI had made CCS extremely accessible by providing Simple, Edit and Debug perspectives. CCS is now my preferred development environment for embedded work, which works great since I’m also a fan of TI’s 32-bit ARM Cortex-M4 MSP432 and 16-bit MSP430 processor families.

CCS is not without its foibles though. For one, it takes a long time to start up. For quick or limited editing I prefer NotePad++, and if I double-click a file in Explorer, NotePad++ is launched not CCS. Also I continue to use TortoiseSVN and GitExtensions outside of CCS. I’ve read there are Plugins available, but that means more learning. NetBeans came with a git GUI built-in and I rarely needed a separate tool.

Here is a quick a refresher for starting a new project after having been away from CCS for a while (it should also apply to CCS v6). 

Tabs vs Spaces

The coding standard followed by the msp432logger project stipulates using tabs to indent code, with a tab width of four spaces. This can be difficult due to how CCS manages tab vs spaces.

CCS provides tab vs spacing preferences (Window -> Preferences -> General -> Editors -> Text Editors “Insert spaces for tabs” enabled or disabled). However, CCS appears to indent a new line according to the convention of the old line (whether tabs or spaces) when Enter is used to create a new line, or when CCS automatically indents based on parentheses (at least with C files). This is regardless of the Preferences setting, and in addition, there is a context menu selection “Uses Spaces for Tab” which must be disabled (right-click in an editor).

Because of the various settings affecting whether indenting will be done with tabs or spaces, it is easy to accidentally introduce and propagate space-based intending within a file. Time will tell if I’ve finally got my preferences set correctly, and it may be simpler to use space-based indenting with CCS if you have the choice. I’m currently watching for spaces in pre-commit diffs, and manually searching and replacing 4-spaces with a tabs using Notepad++ (I haven’t figured out how to specify non-printable characters in CCS search & replace yet). 

Code Folding

Code folding must first be enabled in the Preferences window (Window > Preferences > C/C++ / Editor / Folding) with Show advanced settings selected. Open edit windows must be closed and re-opened before folding will be available.

The configured preferences specify that functions and header comments are to be initially folded. In the screenshot below, the i2cMasterCancel() function has been  expanded.

To quickly expand or collapse all folding, right-click in the left margin of an editor and select Folding from the context menu. 

Split Edit Window (different files)

CCS typically displays files in tabs using the same editor window. To split the editor window and view content from two (or more ) files side-by-side (or top-and-bottom), simply drag the desired tab to the side (or top or bottom) of the editor window.

For example, drag an editor tab to the right margin,

which results in the file appearing in a new editor window to the right.

Split Edit Window (same file)

The method above (moving an editor tab to a new editor) doesn’t work to view different parts of the same file in separate windows. Instead, use

  • Ctrl Shift [
  • Ctrl Shift –

to split the edit window either vertically or horizontally (or to un-split).

So from a single tab,

press ‘Ctrl Shift [‘ to see uartCommand.c in side-by-side panes, 

or ‘Ctrl Shift -‘ to see uartCommand.c in top-and-bottom panes.

 

View Call Hierarchy

CCS show the call hierarchy for a function (i.e. a list of callers of the function). From the CCS Edit perspective, you can right-click on a function and select Open Call Hierarchy from the context menu. 

The screenshot below shows how the i2cMasterSendReceive() is called from the tlvInitSn cli command.

Missing Debugger Buttons in Simple Perspective

The Simple perspective in CCS should show debugger buttons in the toolbar (Run,  Step Into, Step Over, Pause, Stop, etc.) when a debugging session is active, but I have lost the buttons several times now. While switching to the Debug perspective is an option (which should be present in a debugging session) to use the buttons there, I have been able to restore the buttons in the Simple perspective by right-clicking on the menu bar and selecting Restore Hidden Toolbar Entries, then switching perspectives to something else and then back to Simple.

 

Branching in Subversion using TortoiseSVN

It is generally considered good practise with Subversion to keep trunk for stable useable code, and create a development branch from trunk for new development. The new development may be used, for example, to code a new feature, to perform release stabilization, or to experiment with refactoring, and will be merged back into the main branch when the work is complete.

Working on the msp432logger project, I wanted to refactor the code to create a distinct logging application, separate from the driver level, and created a new branch for the work called TRY-loggerapp

Create a development branch

I’m following Subversion best practices for my project directory structure, using trunk, tags and branches sub-directories.

Foresight

Right-click on the local repository workspace folder in Windows Explorer and pick TortoiseSVN -> Branch/tag… from the Context menu. Select the path for the branch, a log message, and the base for the branch. You can select HEAD or a specific version to base the branch on. If there are no edited files in the working copy, the Copy dialog will default to using the most recent version as the base for the branch.

tortoisesvn-07-create-branch-from-head-ok-comments

Hindsight

If you are creating the branch in hindsight and have already made file edits, TortoiseSVN will warn you that basing the branch on HEAD will result in loss of those edits.

tortoisesvn-01-create-branch

In this case, you will likely want your edits (and any new files) to become the first commit in the new branch. In this case, close the warning and select Create copy in the repository from: Working copy.

tortoisesvn-05-create-branch-ok-comments

Work in the dev branch

I selected Switch working copy to new branch/tag in the Copy dialogue when I created the branch. The current branch in the working copy can be verified using the svn info cli command.

tortoisesvn-09-svn-info

You can also see the new branch in TortoiseSVN’s Revision Graph.

tortoisesvn-10-svn-revision-graph

If I hadn’t checked Create copy in the repository from: Working copy when I created the branch, I would have had to Switch to the branch in a separate step.

Right-click on the local repository workspace folder in Windows Explorer and pick TortoiseSVN -> Switch… from the Context menu, and select the path for the branch to switch to.

tortoisesvn-10-switch-to-branch

You can confirm your working copy has switched to the desired branch using the Subversion cli command “svn info” as previously described before continuing development in the new branch.

Checking in code is as before, but first check the Commit to: line at the top of the Commit dialogue to confirm the code will be checked into the correct branch.

tortoisesvn-11-first-commit

After clicking OK, you should see that the check-in completed successfully.

tortoisesvn-12-first-commit-finished

and the Revision Graph now includes the check-in.

tortoisesvn-12-new-revision-graph

Merge dev branch back into trunk

Eventually you want to merge the development branch back into trunk. The preferred method is to start with a clean working copy, check out the branch to merge into (i.e. check out trunk), then use the TortoiseSVN Merge Wizard to merge the desired branch into trunk.

 Start the Merge Wizard.

 

Select Merge Range of Revisions.

Select the branch to merge into the current branch.

Options will not be necessary for basic operation.

The results of the auto-merge will be shown.

The working copy is now modified with the results of the merge.

Test the modified working copy as needed, then commit the modified trunk branch back to the project.

Easy  Peasy!

Cheers,
Dale

TI CCS 6.1.1 and MSPWare MSP-EXP432P401R Example Projects

CCS 6.1.1 included updates to the default MSP432 linker and startup files (copied to a new project created in CCS), but unfortunately it seems the example projects in MSPWare didn’t get the same update.

The fix is simple. After importing an example project into CCS from MSPWare, edit msp432_startup_ccs.c and add “#pragma RETAIN(interruptVectors)” before building and debugging.

Now for the fun bit. If you tried building and debugging BEFORE editing the startup file, you likely loaded crap onto your MSP-EXP432P401R and now it’s bricked (except for “Error -1063” when you try connecting to it from CCS). If that’s the case, perform a factory reset of the MSP-EXP432P401R first to wipe it clean, then load a good build.

Summary of the problem, cause and workaround:  https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/460430/1663082#1663082

How to perform a factory reset: https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/465581/1671110#1671110