An excerpt from a discussion on the TI MSP430 Forums regarding trade-offs between sticking with an old toolchain that you’re used to, and continually updating:
You can stick with an existing, “well understood” system, and assume that you’re safe because it passes what you think is important to test. Or you can keep up to date with what’s provided by a vendor (who sees a lot more use cases and variations than you do). This is a management choice.
All I can say is that, in my own multi-decade experience, the biggest long-term source of destabilization comes not from regular updates to the current toolchain, but from staying with old tools until something happens that forces you to make a multi-version jump to a new compiler. (And I agree that a new version is a new compiler and cannot just be assumed to work; this is why one should develop complete regression suites with test harnesses to check the “can’t happen but actually did once” situations.) I can’t see what happens in proprietary systems, but it’s been many years since an update to GCC has resulted in my discovery of an undesirable behavioral change that wasn’t ultimately a bug in my own code, with the fix improving quality for that code and all code I’ve worked on since.
If you’re operating in a regulated environment where the cost of updating/certifying is prohibitive, so be it. Best approach in that case is to keep with the toolchain used for original release of the product, and release new products with the most recent toolchain so you’re always taking advantage of the best available solution at the time.
I’m not saying there’s a universally ideal policy, e.g. that you should always use the current toolchain. I am saying that a shop that develops and releases new products using old toolchains without a strong reason behind that decision is not using best practices and is likely to produce an inferior product. If management thinks they’re saving money and reducing risk by not updating, there’s a good chance they’re being short-sighted.
Two years ago a launchpad version of TI’s ultra-low-power FRAM-based Wolverine chip was demonstrated at Embedded World 2012. The MSP-EXP430FR5969 was finally released a couple weeks ago.
I first got a Wolverine (MSP430FR5969) chip back in August 2012 by badgering TI to send them to me and Daniel Beer so the open source toolchain comprising mspgcc and mspdebug would support them when the launchpad was released. That lash-up has been in BSP430 since October 2012, but wasn’t really usable. As of today, full support for EXP430FR5969 has been added to BSP430.
The device has a standard 14-pin JTAG header, and also supports the eZ-FET emulator through the micro-B USB connector as the first of the two interfaces (generally showing up as /dev/ttyACM0 on Linux). This emulator can be used with the “ezfet“ driver under mspdebug. Which I suppose is good since you don’t need the MSP-FET430UIF, but check this comparison:
llc$ time mspdebug ezfet "prog app.elf" > /dev/null
llc$ time mspdebug tilib "prog app.elf" > /dev/null
llc$ msp430-size app.elf
text data bss dec hex filename
30011 542 1370 31923 7cb3 app.elf
Four times faster with the FET430UIF. 15 seconds is overhead, the rest is just that eZ-FET is slower per byte transferred. I lived with this for six hours before I was comfortable enough to try the same fix I used for the EXP430F5529LP: disconnect everything, plug in only the EXP430FR5969, then run:
# verify you get a notice saying the firmware needs to be updated
# do the update
sudo mspdebug tilib --allow-fw-update
Yes, you do have to do that as root even if you have udev rules allowing user-level access to the device: during the firmware update the vendor/product IDs change and those rules won’t apply. Now I can put the FET430UIF back in the closet.
Other miscellaneous items of interest:
So: The device works, but is clearly still experimental (as indicated by the X430FR5969 part number, and the warning sheet included in the box). Good enough to bring BSP430 up to twelve supported platforms, though.