PlatformIO Community

MSP430F5521 (instead of MSP430F5529)

Hi PIO community,
I have a custom PCB using an MSP430F5521 which is very similar but not identical to the MSP430F5529 as it is used in the launchpad. The differences can be found in the memory organization, all other peripherial should be identical.
I can compile and it even seems to take the right memory segments.

But unfortunately flashing the firmware using mspdebug is not possible as i cannot use board = lpmsp430f5521in the platformio.ini file (Error: Unknown board ID ‘lpmsp430f5521’).

When pretending to use the other MCU with board = lpmsp430f5529 mspdebug detects the mismatch and returns this → error: MSP430: Error connecting to the target: The target setup (MSP430F5529) does not match the actual target type (MSP430F5521)

platform = timsp430
board = lpmsp430f5529 ;lpmsp430f5521 leads to this --> Error: Unknown board ID 'lpmsp430f5521'
board_build.mcu = msp430f5521 ; change microcontroller
board_build.f_cpu = 24000000L ; change MCU frequency
debug_tool = mspdebug
build_flags =

Any help is appreciated

maybe another json file similar to this one? platform-timsp430/lpmsp430f5529.json at develop · platformio/platform-timsp430 · GitHub

Indeed, as board = .. values you only use the filenames (without the .json extension) existing in the platform or the ones supplied by the project’s boards/ directory (docs) of the project. So if you want to use board = lpmsp430f5521 there has to be a boards/lpmsp430f5521.json file in the project with the modified JSON manifest data, e.g. based on the one you’ve already linked above. That would be the cleanest way. I’d suggest using the content

  "build": {
    "core": "msp430",
    "extra_flags": "-DENERGIA_ARCH_MSP430 -DENERGIA_MSP_EXP430F5521IPN",
    "f_cpu": "25000000L",
    "hwids": [
    "mcu": "msp430f5521",
    "variant": "MSP430F5521IPN"
  "debug": {
    "tools": {
      "mspdebug": {
        "onboard": true,
        "server": {
          "arguments": [
          "executable": "mspdebug",
          "package": "tool-mspdebug"
  "frameworks": [
  "name": "TI MSP430F5521",
  "upload": {
    "maximum_ram_size": 6144,
    "maximum_size": 32768,
    "protocol": "dslite"
  "url": "",
  "vendor": "TI"

Hm maybe that error goes away after using the JSON definition above, but I think for uploading is done via the GDB server opened by mspdebug but statically via dslite. And that accesses also the variant datafield of the board definition which you left at its default

So the logic above computes MSP-EXP430F5529LP.ccxml as the used configuration file for the upload when you only change board_build.mcu and not board_build.variant. However, in order for you to change the variant to another value, that file has to actually exist in the tool-dslite folder, but looking at C:\Users\<user>\.platformio\packages\tool-dslite folder…


there is no CCXML definition for a MSP430F5521(IPN), which is a problem.

However, looking at e.g. MSP430F5529.xml, the file is mainly boilerplate code and then includes the actual content file

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configurations XML_version="1.2" id="configurations_0">
<configuration XML_version="1.2" id="TI MSP430 USB1_0">
        <instance XML_version="1.2" desc="TI MSP430 USB1_0" href="connections/TIMSP430-USB.xml" id="TI MSP430 USB1_0" xml="TIMSP430-USB.xml" xmlpath="connections"/>
        <connection XML_version="1.2" id="TI MSP430 USB1_0">
            <instance XML_version="1.2" href="drivers/msp430_emu.xml" id="drivers" xml="msp430_emu.xml" xmlpath="drivers"/>
            <platform XML_version="1.2" id="platform_0">
                <instance XML_version="1.2" desc="MSP430F5529_0" href="devices/MSP430F5529.xml" id="MSP430F5529_0" xml="MSP430F5529.xml" xmlpath="devices"/>

devices/MSP430F5529.xml, which is in [..]\tool-dslite\common\targetdb\devices.

Sadly again no 5521 definition exists…


However, and this is finally where the good part comes in, an updated version of the DSLite / UNIFLASH tool (UNIFLASH Software programming tool | actually has the definition, for this and many more chips


But when looking at that file, one case see that it’s absolutely identical to the 5529 file (peripherals and everything), with the exception of a changed id and partnumber value saying 5521 instead of 5529, and a path to some linker file, which can also be copied from the newer version.

Long story short: I’ve updated my forked platform with a board definition for the 5521 and created an extended version of the tool-dslite tool which should have the right definitons for the chip.

Try and use the platformio.ini

platform =
board = lpmsp430f5521
debug_tool = mspdebug
; upgrade to 9.3.1, binary distribution uploaded here, **WINDOWS ONLY**
; upgrade tool-dslite with definitions for MSP430F5521IPN
platform_packages = 

to test this change. You will need to remove the C:\Users\<user>\.platformio\platforms\timsp430* folder(s) to trigger a redownload of the new git version.

Or use it with the standard / old platform and the additional boards/lpmsp430f5521.json file as per here, but remember you’ll still need at least platform_packages = tool-dslite@ to get upload working.

Thanks a lot @maxgerhardt it is working! I actually did a similar thing by copying the following files and renaming anything with 5529 to 5521 (filenames and content).

  • *.platformio\platforms\timsp430\boards\lpmsp430f5529.json
  • *.platformio\packages\tool-dslite\MSP-EXP430F5529LP.ccxml
  • *.platformio\packages\tool-dslite\common\targetdb\devices\MSP430F5529.xml
  • *.platformio\packages\tool-dslite\common\targetdb\options\MSP430F5529_TI.xml
  • *.platformio\packages\tool-dslite\common\targetdb\options\MSP430F5529_GNU.xml

I also think i start to grasp the idea of how to keep these changes on platforms or toolchains even when working on a different machines by using github repositories.