Badly formatted error during debug

Hello, I’ve just started using PIO and ran into some problems. Some details
PIO version 4.3.3 / 3.2.2
Platform: timsp430
Framework: Arduino

Problem 1: compile flags. Solved this by adding (debug_build_flags = “-O0”, “-g3”, “-ggdb” “-gdwarf-2”) in platformio.ini. It was complaining about -Og. I can download the program fine.

Problem 2: While trying to debug, I get the following error.

Device: F20x2_G2x2x_G2x3x (id = 0x0035)
2 breakpoints available
Chip ID data:
ver_id: 01f2
ver_sub_id: 0000
revision: 30
fab: 40
self: 0000
config: 02
Device: F20x2_G2x2x_G2x3x
Bound to port 2000. Now waiting for connection…
.pioinit:11: Error in sourced command file:
Remote register badly formatted: T0500:00f80000;01:74020000;02:00000000;03:00000000;04:ffce0000;05:085a0000;06:effe0000;07:3ff60000;08:6f030000;09:00000000;0a:a8440000;0b:b9860000;0c:a35c0000;0d:43000000;0e:40050000;0f:00000000;
here: 0000;01:74020000;02:00000000;03:00000000;04:ffce0000;05:085a0000;06:effe0000;07:3ff60000;08:6f030000;09:00000000;0a:a8440000;0b:b9860000;0c:a35c0000;0d:43000000;0e:40050000;0f:00000000;

This is where I have no idea what to do next. Any suggestions?


  • full platformio.ini and test code?
  • with which development board are you working with?
  • have you made sure to be on the latest platform version? (Update platform & packages task or pio platform update)
1 Like

I’m having the same issue, and found this similar issue: Unable to use mspdebug tool using MSP430G2452 · Issue #15 · platformio/platform-timsp430 · GitHub

For my platformio.ini:

; PlatformIO Project Configuration File
;   Build options: build flags, source filter
;   Upload options: custom upload port, speed and extra flags
;   Library options: dependencies, extra library storages
;   Advanced options: extra scripting
; Please visit documentation for the other options and examples

platform = timsp430
board = lpmsp430g2553
debug_build_flags = -O0 -g2 -ggdb2
debug_tool = custom
debug_port = :39102
debug_server = 
    "gdb 39102"

I’m running on macOS Catalina with a TI Launchpad MSP-EXP430G2 w/ MSP430G2553 and a modified kernel extension. The kernel extension works because when I run mspdebug outside of platformio, it successfully communicates with the launchpad (break, step, and run make the factory blink program stop and start as expected) although I have yet to download a program using either. I am not using arduino or energia (I intend to use native), so my main.cpp program is just:

int main() {}

I get a similar error:

Processing lpmsp430g2553 (platform: timsp430; board: lpmsp430g2553)
Verbose mode can be enabled via `-v, --verbose` option
PLATFORM: TI MSP430 2.2.0 > TI LaunchPad MSP-EXP430G2553LP
HARDWARE: MSP430G2553 16MHz, 512B RAM, 16KB Flash
DEBUG: Current (custom) On-board (mspdebug)
 - toolchain-timsp430 1.40603.190926 (4.6.3)
LDF: Library Dependency Finder ->
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio/build/lpmsp430g2553/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   0.4% (used 2 bytes from 512 bytes)
Flash: [          ]   0.7% (used 112 bytes from 16384 bytes)
========================= [SUCCESS] Took 1.28 seconds =========================
MSPDebug version 0.23 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2015 Daniel Beer <>
This is free software; see the source for copying conditions.  There is NO
Chip info database from MSP430.dll v3.3.1.4 Copyright (C) 2013 TI, Inc.
Trying to open interface 1 on 008
Initializing FET...
FET protocol version is 30394216
Set Vcc: 3000 mV
Configured for Spy-Bi-Wire
Using Olimex identification procedure
undefinedfet: FET returned error code 4 (Could not find device or device not supported)
fet: command C_IDENT1 failed
Device ID: 0x2553
  Code start address: 0xc000
  Code size         : 16384 byte = 16 kb
  RAM  start address: 0x200
  RAM  end   address: 0x3ff
  RAM  size         : 512 byte = 0 kb
Device: MSP430G2xx3
Number of breakpoints: 2
fet: FET returned NAK
warning: device does not support power profiling
Chip ID data: 25 53
Bound to port 39102. Now waiting for connection...
Reading symbols from /Users/gregory/Documents/PlatformIO/Projects/Launchpad Test/.pio/build/lpmsp430g2553/firmware.elf...
PlatformIO Unified Debugger ->
PlatformIO: debug_tool = custom
PlatformIO: Initializing remote target...
Client connected from
Clearing all breakpoints...
Connection closed
.pioinit:13: Error in sourced command file:
Remote register badly formatted: T0500:c2fc0000;01:7a020000;02:00000000;03:00000000;04:b74d0000;05:07160000;06:4f850000;07:cfe90000;08:97e00000;09:a2d60000;0a:fb840000;0b:7a8e0000;0c:00000000;0d:90fd0000;0e:00000000;0f:ffff0000;
here: 0000;01:7a020000;02:00000000;03:00000000;04:b74d0000;05:07160000;06:4f850000;07:cfe90000;08:97e00000;09:a2d60000;0a:fb840000;0b:7a8e0000;0c:00000000;0d:90fd0000;0e:00000000;0f:ffff0000;

I get the same error using mspdebug v0.24 and v0.25 (latest) refuses to connect to the launchpad at all.

I don’t want to hijack the thread, but this seemed the right place to put this since it’s the most recent thread on the topic.


One further note I just discovered, everything works fine when just uploading using the same configuration except adding upload_protocol = rf2500 to the platformio.ini (meaning a program downloaded and ran successfully). It seems to be a problem with just debug mode.

Update: It works now!

After lots more investigation, I found there is a bug in mspdebug as explained in this issue: gdb and mspdebug communication · Issue #78 · dlbeer/mspdebug · GitHub. Following the advice to remove the two lines

if (strstr(buf, "multiprocess+"))
			register_bytes = 4;

from ui/gdb.c fixes the issue for me so far.

Note that there is an error with the rf2500 device I am using with the v0.25 release from the GitHub repo as explained in this issue, On Mac Os High Sierra rf2500: failed to open RF2500 device · Issue #77 · dlbeer/mspdebug · GitHub.

1 Like

Interesting, so a new version of mspdebug should fix the problem for all used GDB versions? The issue 78 is still open though, was the fix ever merged?

Yes, the fix is not yet merged, so you’ll have to manually make that fix.