VSCode and MSP430 debugging

In process of getting cozy with VSCode and playing with MSP430 via LanchPad here is a simple recipe for tooling my work up.

But first ...

Basic tooling

• Build -  uses msp430-gcc.
• Debug - uses: mspdebug and msp430-gdb

All msp430 tolls already prepackaged on multiple Linux distros (I use Mint which is Debian-based hence apt-get is your fried.)

Checking Connection to the Target

mspdebug rf2500 "exit"


If the output contains Device ID and Chip ID data you're good.

If it can't connect try again with sudo in case the problem is with permissions. If it works with sudo, you add udev rules to allow non-root access - plenty of info in the tubes on this (I would advice a reboot after adding rules file).

Sometimes, the hw debugger/drive gets stuck - a reconnect would fix it. Make sure it shows connected with 'lsusb|grep 430'.

Flashing the image into the device

mspdebug rf2500 "prog ./bin/firmware.elf"

Starting gdb Debug Server

The server is build into mspdebug it need to be running as gdb will use it to debug.

mspdebug rf2500 "gdb"

Starting gdb Proper

msp320-gdb bin/firmware.elf -ex "target remote :2000"

This tells the gdb to load debug info from the given elf file and execute commands to connect to the debug server. Normally, gdb uses this for remote debugin (as in on another PC) here the same is used for embedded systems.

NOTE: each time you disconnect/quit gdb the debug server must be restarted.

Convinience - Make File Targets

In the Ikea Ansluta hacking project (on github here) I have created make targets for continence:

make target-flash

make target-startdebug

make target-debug

I think it's easier to remember these than particular incantation of commands given above.

The CLI workflow would be:

edit+build with make

flash with make target-flash

debug with make target-debug

Note that target-flash makes sure the code build is up to date.

VSCode tooling

By adding tasks: build and flash I can Ctrl-Shift-B to build (as normal with VS) and I can also flash directly from the IDE be selecting "Flash" task. These are added to .vscode/tasks.json file manually. 

Starting debbugger with just F5 is tooled via .vscode/launch.json. This tells VSCode to use "msp430-gdb" instead of default one and it tells it to connect to remote debug server.

However, I could not make the a preLaunchTask to start the msbdebug in the background. This task seem to either exit and kill the mspdebug or the mspdebug is unable to connect despite the rules working file in shell. So for now the debug server must be started manually before entering visual debugging in the IDE.

Ikea Ansluta Hacking - timer and key interrupts

That...was easy.

1) setup interrupt for P1 on P_KEY (the switch) pin

P2IFG = 0; // clear flags register
P2IE = P_KEY; // enable
P2IES = P_KEY; // edge

2) setup timer A0 to use SMCLK/8 and count up, start it

CCTL0 = CCIE; // CCR0 interrupt enabled
TACTL = TASSEL_2 + ID_3 + MC_1; // TASSEL_2 --> SMCLK (~1MHz), MC_1--> up, ID_3 --> SMCLK/8
CCR0 = 50000; // (SMCLK/8)/50000 = 2.5 Hz

3) enter a low power mode with wake on interrupt

_BIS_SR(CPUOFF + GIE);


4) in timer A0 - toggle the LED pin

#pragma vector = TIMERA0_VECTOR
__interrupt void Timer_A(void)
{
   P1OUT ^= P_LED; // toggle LED for now
}

5) in Port 1 interrupt - toggle the max count of timer A0 between 'slow' and 'fast' blinking.

#pragma vector = PORT2_VECTO
__interrupt void Port_2(void)
{
   // TODO - there is no debouncing of the switch
   if( P2IFG & P_KEY )
   {
      CCR0 = CCR0 > 10000 ? 10000 : 50000; // toggle between two blink speeds
   }
   P2IFG = 0; // clear all flags
}

Next: debounce the key, talk to CC2500.

Ikea Ansluta Hacking - bang on the pipes (or...LED)

After achieving target control and reverse engineering the original firmware, the next step was to test development abilities: code, build, flash, debug.

Bang

The 'bang on the pipes' or 'flash LED'.

while(1)
{
LED(1);
DELAYLOOP(0xFFFF)
LED(0);
DELAYLOOP(0xFFFF)
}

Well, that's simple, eh? There some more code in main.c up front to setup the MPU. The Ansluta's specific definitions are all in ansluta.h.

The project is in github (later it may move beyond just flashing the LED).
https://github.com/michkrom/msp430-ansluta


The project builds from CLI on Linux (I now use Mint) but also contains VSCode workspace, intellisense and task definitions.

On VSCode

I have abandoned Geany for VSCode for several reasons (it's shiny, integrates with git, it's used everywhere, it's good at at-hoc projects).  Yes, VSCode is a bit "fatter", being an Electron app, but it still works on my old-but-good 10yr laptop w/ 2GB of RAM with Mint x64.

Next Steps

Two "targets" (pun intended): get timer to flash led, get key press to work - all with interrupts. Then,  talk to CC2500 radio.