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:

llc[287]$ time mspdebug ezfet "prog app.elf" > /dev/null
real    0m34.338s
user    0m0.064s
sys     0m0.236s
llc[288]$ time mspdebug tilib "prog app.elf" > /dev/null
real    0m8.095s
user    0m0.032s
sys     0m0.016s
llc[289]$ 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
mspdebug tilib
# 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:

  • 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.

Leave a Reply

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