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)
[env:lpmsp430f5521]
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 =
-Wall
-Wl,-Map=output.map
Indeed, as board = .. values you only use the filenames (without the .json extension) existing in the platformor 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
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…
However, and this is finally where the good part comes in, an updated version of the DSLite / UNIFLASH tool (UNIFLASH Software programming tool | TI.com) 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
[env:lpmsp430f5521]
platform = https://github.com/maxgerhardt/platform-timsp430.git
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 =
toolchain-timsp430@https://github.com/maxgerhardt/pio-toolchaintimsp430-new.git
tool-dslite@https://github.com/maxgerhardt/pio-dslite-extended.git
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@https://github.com/maxgerhardt/pio-dslite-extended.git 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).
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.
