On using current toolchains

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.

EXP430FR5969 Launchpad First Experiences

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:

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:

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:

  • In the current silicon and user’s guide, PM5CTL0.LOCKLPM5 powers up set. Unless explicitly cleared, no GPIO configuration takes effect. This includes useful things like “I’m alive” LED blinks. Since that behavior wasn’t present in the original FR58xx user’s guide or the old XSPFR5969 chips I got two years ago, I spent a few minutes wondering why the board didn’t blink after programming. KatiePier at 43oh to the rescue and now BSP430 clears that bit when the board is initialized. (And yes, of course you can prevent it from doing so, or hook in before it happens, so you can properly handle wakeups from LPM x.5.)
  • The micro-B USB port provides a back-channel UART that shows up as the second interface (/dev/ttyACM1). This uses EUSCI A0, while EUSCI A1 is connected to the standard launchpad UART pins (A.3 and A.4).
  • One of BSP430’s board-raising applications sends the MSP430 clock signals to headers so they can be externally validated; that’d be MCLK (the master CPU clock); SMCLK (sub-master for peripheral clocks); and ACLK (auxiliary clock). The EXP430FR5969 does not make any of these easy to get to: they’re only accessible on the JTAG header.
  • I’m unable to set the clock speed above 8 MHz; the next setting is 16 MHz, and an oscillator fault is generated immediately after CSCTL3.DIVM is cleared to produce an undivided MCLK (the power-up setting divides by 8). This is not an erratum listed in SLAZ473E, but 16MHz is the maximum listed operating speed. I was able to run at 12MHz by using a 24MHz DCOCLK with DIVM_2.
  • The CC3000BOOST booster pack works if powered through the DC jack. The Anaren Air CC110L booster pack also works.
  • Each device has a unique 128-bit number in the TLV region with tag 0x15.
  • The ADC12_B is a 32-channel converter, and the standard internal and voltage inputs are disabled by default (and are not on the traditional channels 10 and 11). The new revision E chips are subject to erratum ADC40, described as

    The ADC module may return large errors in its conversion results. The probability of conversion results with large errors varies depending on temperature and VCC.

    and notes that the workaround is “None”. I’m seeing 5% errors randomly on temperature and voltage reads with all three reference voltage levels.

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.