CMake + MSP430

I have a dream :)
Actually, it's a very simple wish: to use the well known CLion IDE for embedded systems on msp430 chips.
I'll try to report the topic in 2 posts. Here is the first one.

My reasons

First, I like CLion for a lot of features and I've spent $71 to buy the year's license. Money has to work :)
Second, my ADC-PLC project is based on MSP430FR5726 chip. It was OK, as far as I was implementing only ADC functionality. But later on, the code has broken the 16K size. So I had to choose the new family of MCUs. There are MSP430FR5959 chips among my MCUs now. They happily contain 64K of FRAM - and we have to use it!
Texas Instruments propose their very good Code Compose Studio (CCSv7.3 at present time). As a toolchain to build C-programs we have a choice:

1. TI v16.9.4.LTS (proprietary, 16K code limit free)
2. GNU v.6.4.0  (opensource, developed by Red Hat and TI, maintained by Somniun Technologies)

I like TI toolchain very much. At the least, it gives a notably shorter code (I had to compare when there was to little room in 5726 MCU). But I'd rather used the free version. So GNU is the choice for me.
So far, I used CCSv7.3 with GNU toolchain (or, alternatively, Code::Blocks without step-by-step debugging).
But the best kills good! I don't mean the evil of perfectionism, no. I mean that CLion is too good to use anything else, from my humble point of view. So it killed a CCS as mine tool.
Not earlier than I perform a CLion setup, of course.

My roadmap

1. Make CLion work with the MSP430-GCC toolchain
2. Run flashing and debug in the IDE with the hardware target

The point 1 is the scope of this post.

My sources

Well, the CLion people and users give us not much for the topic. Their info is scattered around and I found it not easy to find relevant to my case. Yet, the CLion team is responsive and they helped me to find all they have.

• CMake toolchain by Shashank Chintalagiri was the most productive for me;
• CMake Cross Compiling in CMake Wiki is very useful for beginners in CMake;
• several videos from JetBrains, which I'm too lazy to search again;
• CLion for embedded development by Ilya Motornyy in CLion Blog, though the post deals with the STM32 and, what is more important, the debugging is performed via Ozone (SEGGER) Cross Platform Debugger. The last makes the article not very useful in debug domain;
• Developing for AVR with JetBrains CLion on Mac OS" by Tom Lankhorst with debugging included
• Using CLion for AVR development by Andreas Haufler has inspired me by "That was quite easy to do" phrase :)

Disclaimer

I've not arrived straightforward at the point I report now. Being rather a noob in sysadmin tasks, I had to go circles and cycles till some progress was achieved. Thanks to the great CMake toolchain files of Shashank Chintalagiri and thanks to his eager support of my efforts, the insertion of MSP430 GNU toolchain was successful. Since I've never got the whole scope of Shashank's system, I left the structure/features of the toolchain as I've got it: 

• the isolated toolchain directory, 
• Platform subdirectory,
• all the power of adding new chips ("devices"). 

It is highly possible that one of you will transform this structure, simplify it or add more power.

I use it AS IS and it suits my tasks.

End of disclaimer

Main_action_of_the_topic()

All relevant files on Github 

1. Structure and files: project

The sample project structure is standard for CLion. You may find in CLion doc how to create new C-project and you'll obtain this tree:

├── cmake-build-debug
├── CMakeLists.txt
├── main.c
└── oooo-msp430fr5959.ld

As usual, cmake-build-debug is that ugly name for CMake-generated files (including Makefile) and make-generated target files (including .ELF, .SYM and so on).

File CMakeLists.txt is short and simple:

cmake_minimum_required(VERSION 3.5)

project(oooo)

set(SOURCE_FILES main.c)

add_platform_executable(oooo "" ${SOURCE_FILES})

You may see the custom function add_platform_executable(). It's defined in toolchain file later.

Source file may be the usual BLINK:

#include <msp430.h>
int main(void) {
    WDTCTL = WDTPW | WDTHOLD;
    PM5CTL0 &= ~LOCKLPM5;
    P1DIR |= 0x01;
    for(;;) {
        volatile unsigned int i;
        P1OUT ^= 0x01;
        i = 10000;
        do i--;
        while(i != 0);
    }
    return 0;
}

The Linker command file oooo-msp430fr5959.ld is optional. I use a custom command file for Linker. Usually, I place it among the source files since it's being edited with these files. Look the ELF_FILE target in the msp430-gcc.cmake file and change commented/uncommented lines there if you'd prefer to use the standard file.

Apart from project directory, we have toolchains' files. 

2.  Structure and files: toolchains

As Shashank writes in his comments:

You should keep the toolchains folder unbroken. The toolchain.cmake file needs to be next to the Platforms folder ... and not in the project itself if you're using my toolchains. This is because the toolchain is designed to leave the decision of the target device floating as late as possible - and lets me compile stuff to a wide range of targets from a single build folder.

And later:

If you look at the Platform file, you will see that this generates the many targets and assigns the correct dependencies for each, built for the appropriate device, to the executable. The platform files, therefore, provide a set of functions which are not standard to cmake, which wrap around standard cmake functions and add functionality required for fancy cross compiling to it.

So I created ~/toolchains directory:

├── burn-eZ-430.sh
├── burn-eZ-FET.sh
├── gdb-server.sh
├── Platform
│   └── msp430-gcc.cmake
└── toolchain-msp430-gcc-ti.cmake

Files toolchain-msp430-gcc-ti.cmake and msp430-gcc.cmake are very important in our setup since the usual toolchain files I've tried, according to CLion and CMake manuals, gave no positive result.
Toolchain file toolchain-msp430-gcc-ti.cmake specifies pathnames of all tools needed. In my case, it's a toolchains directory and msp430-gcc Linux-64bit toolchain.
Note that I've eliminated all paths to programs making the upload of the code on the target MCU ("burn"), such as MSPFlasher and MSPDEBUG. We'll speak about it in the 2-nd part.
Platform msp430-gcc.cmake file deals with all possible targets on the whole DEVICES list. Two notes:
First, I use custom Linker command fiie, as I've mentioned above.
Second, UPLOAD is passed to IDE, so target ${EXE_FILE}-${device}-upload points to HEX file as dependency and does nothing except it.
Scripts burn-eZ-430.sh, burn-eZ-FET.sh, gdb-server.sh are being discussed in part 2. They have nothing to do with project building and so they are not relevant here.

3. CLion settings

What has been changed in standard project settings:

Build, Execution, Deployment -> Toolchains: Nothing. Actually, I've added 2 toolchains, but they deal with debugging, not building. Leave it for the part 2.

Build, Execution, Deployment -> CMake -> CMake options:  

-DCMAKE_TOOLCHAIN_FILE=/home/user/toolchains/toolchain-msp430-gcc-ti.cmake

As you can see, everything is similar to the recommended setup for cross-compiling. 

At this point the CLion checks settings (I used to launch  Tools -> CMake -> Reset Cache and Reload Project) and it has to finish without errors. If so, the CLion has a set of tools to build a project.

First build ALL gives the output:

[ 50%] Building C object CMakeFiles/oooo-msp430fr5959.elf.dir/main.c.obj
[100%] Linking C executable oooo-msp430fr5959.elf 
[100%] Built target oooo-msp430fr5959.elf
   text    data     bss     dec     hex filename
    538      28      22     588     24c oooo-msp430fr5959.elf
[100%] Built target oooo
[100%] Built target oooo-msp430fr5959.size
[100%] Built target oooo-msp430fr5959.sym
[100%] Built target oooo-msp430fr5959.hex
[100%] Built target oooo-msp430fr5959.lst

That's all with the Compiler. Next part deals with the uploading and debugging