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.

3 thoughts on “EXP430FR5969 Launchpad First Experiences

  1. Peter Bigot Post author

    Back on 43oh, greeg points out that the newer FR58xx devices require you to manually manage wait states (FR57xx do not, nor did the original Wolverine chips I got). I’ve updated BSP430 with infrastructure to put this under platform control, and can actually run the unit at 24MHz though it’s rated only for 16MHz.

  2. Andrew Wygle

    When trying to bring up my new EXP430FR5969, I found that the ezfet driver didn’t work for me:

    % mspdebug ezfet
    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.

    Reset communications…
    Version:, HW: 0xaaaaaaaa
    Reset firmware…
    hal_proto_execute: HAL exception: 0xffff
    hal_proto_execute: fid: 0x51

    After this process the device essentially disappears. The tilib driver works, but only if I don’t try the ezfet driver first.

    Working tilib is good enough for now, but I wondered if you might have seen this in your testing, and have some insight into what’s causing it.

    1. Peter Bigot Post author

      In short, no, I don’t recall seeing that, but never did try to figure out how all the FET stuff worked on these boards. I prefer tilib because it is so much faster.


Leave a Reply

Your email address will not be published. Required fields are marked *