New MSP430F5529 USB Launchpad Released

[rampadc 29]

Did you guys notice TI's selling their new MSP430F5529 USB Launchpad board? I found an old announcement back in 2012 on 43oh main page that TI's working on it but haven't seen any on it being sold. I just found out today and apparently it's sold out. :-(

 

TI also changed the descriptor tool by making the interface a bit prettier but they removed the definition USB_MCLK_FREQ which will break all the code in their last USB API so now there's a new USB API 4.0 that requires CCS 5.5 to be installed, though there are workarounds so it will work with existing CCS. 

Edited September 12, 2013 by bluehash
Title Edit.

[nemetila 12]

It was new to me.

 

More info on ti.com :http://www.ti.com/tool/MSP-EXP430F5529LP

and on wiki.ti: http://processors.wiki.ti.com/index.php/MSP430F5529_LaunchPad

 

Price: $12.99(US$) 

 

 

Features

• USB 2.0-enabled MSP430F5529 16-bit MCU
• Up to 25 MHz
• 128KB Flash and 8KB RAM
• 12 Bit SAR ADC
• Various USB device class examples and libraries available (CDC, HID, MSC)
• eZ-FET lite: Open source onboard debugger with application UART
• One USB connection for emulator and target via the use of an onboard USB hub
• USB as power source: 5V and 3.3V through a high efficiency DC/DC converter
• 40 pin LaunchPad standard leveraging the BoosterPack ecosystem 

[SteveR 20]

Update 9/16: FedEx just dropped it off - time to play

 

I saw it yesterday, and one is expected to ship to me today. If it ships I should have it Friday afternoon. 

[jazz 209]

It seems that debugging part is new, based on MSP430F5528 with TUSB hub chip. Debugging (with USB-UART bridge) and target USB connection over only one micro USB connector.
 

[oPossum 1,083]

TUSB3410 is gone - that is the USB hub chip.

[jpnorair 340]

It seems that debugging part is new, based on MSP430F5528 with TUSB hub chip. Debugging (with USB-UART bridge) and target USB connection over only one micro USB connector.

 

 

TUSB3410 is gone - that is the USB hub chip.

 

YAY! This means it will be a lot more stable on Linux and Mac.

 

I'm also psyched about the 5529 LP in general. It's something that I can work with as a WSN kit. I just need to ship a booster pack with RF and an antenna on it, with SPI to the 5529. Easy.

[jazz 209]

TUSB3410 is gone - that is the USB hub chip.

 

Yes, TUSB2046B 4-Port Full-Speed Universal Serial Bus Hub

[juani_c 66]

It seems that debugging part is new, based on MSP430F5528 with TUSB hub chip. Debugging (with USB-UART bridge) and target USB connection over only one micro USB connector.

 

It seems to be the new " New eZFET (on-board emulation)" used also in the MSP-EXP430FR5969 Wolverine

[rockets4kids 204]

YAY! This means it will be a lot more stable on Linux and Mac.

 

I have never had *any* problems with the MSP430 LaunchPad under OSX.  IME it is by far the most stable host platform.

[spirilis 1,265]

Alright so, I had to keep a zip on it til now but since it's released... I had early access to one of these (thanks to the TI folks!) and got to play with it a little ahead of time.  I'm going to dump my thoughts & observations:

 

1. New eZFET is based on the MSP430.DLL V3 open-source FET library, same as what they use with the FET430UIF.  See http://processors.wiki.ti.com/index.php/EZ-FET_lite

 

You will need the MSP430.DLL (compilable on Windows and Linux; CCSv6 early adopter beta has a binary with full support for it, CCSv5 might not) to use it with "mspdebug" ... I think it's supposed to work on the Mac too but I tried compiling the MSP430.DLL crap months ago and gave up.  For now I compile on my Mac using mspgcc 4.7.0 and scp over to my Windows netbook where I run "mspdebug tilib" with CCSv6 beta's MSP430.DLL to program & debug it.

 

2. The literature all mentions Energia, so I expect a full release of Energia is forthcoming soon.  Might be why they've been waiting so long to release an update.  I expect they will have got MSP430.DLL compilation on the Mac working for this release so I can quit worrying about copying the firmware & using my Windows machine ..... for everything including FET430UIF uses

 

3. eZFET's backchannel UART has 2 new lines; CTS and RTS.  I think these are implemented in the serial link so your PC's terminal program can use them, but on the MSP430 hardware side they merely connect to 2 random lines on the F5529: CTS is a signal from PC-to-F5529 and goes to P1.7 so it's interrupt-capable, RTS is a signal from F5529-to-PC and is connected to P6.7.  The documentation for the FET expects you to use these lines for handshaking when you use UART speeds over 200Kbps I believe.

 

4. I do love the new documentation sheet; it's colorful and way more explanatory than the others I've seen.  Rei Vilo's energia pinout diagrams inspired this BTW.

 

5. Those stackable wire-wrap headers are a pain in the ass.  I couldn't get my Nokia 1202 boosterpack working with this (very flaky problems, including flickering in the backlight) until I bolstered the thickness of the pins with some flux+solder.  Stellaris & Tiva-C LP has the same problem though.

 

6. There is a nasty glitch that TI should fix ASAP (and they do know about it), preferably with a back-fix for existing boards.  The TUSB hub chip holds the reigns on a couple power switch ICs that let 5V pass through to the eZFET and to the F5529's nets.  If there is no real PC on the other end of the USB connection, the TUSB chip never switches the power on.  So you HAVE to have this board plugged into a PC to power it up using the built-in USB port.  Maybe I'm overblowing this one but it's a basic feature we've been able to take for granted on pretty much every dev board on the market... in a pinch you can always plug your project into a USB cellphone charger or battery power brick, but not with this board.

 

I suppose one could argue that with real low-power requirements, nobody's using that USB port anyway.  However I'm not sure, seeing as they used a high-efficiency DC-DC converter for the 3.3V rail and I'm betting that F5528 eZFET chip goes into LPM4 if it has nothing else to do. But still, USB and ULP don't usually go hand-in-hand.

 

7. Board comes with a cool little USB demo, pushbuttons act like keyboard output and you can browse the contents of a USB mass storage device that shows up.  Reinforcing the urgency behind #6, I think a typical use-case for this board will be sensor sampling "in the field" that you can transfer easily to a PC using a USB mass-storage + CSV output generator feature in the firmware.  Or maybe WiFi config or other RF config can be done using easy text files that get dumped onto the USB mass-storage drive.

 

8. @@pabigot 's MSPGCC 4.7.0 release, his last one, supports the >64KB address space on this chip using -mmemory-model=large or -mmemory-model=huge.  I've tested this out

 

9. The RAM is actually 10K; 8KB + 2KB USB RAM that can be used for general purposes if the USB subsystem isn't switched on.  Linker scripts have to be adjusted to use that extra 2KB, but what's funny is in my copy of the msp430mcu files (headers + linker scripts) that Peter released, looking in the msp430f5529 directory there is a "nousb" dir with an alternative memory.x linker script file:

total 40
drwxr-sr-x@   6 ebrundic  staff    204 Sep  4 12:34 .
drwxr-xr-x@ 440 ebrundic  staff  14960 Jul  1 12:06 ..
-rw-r--r--@   1 ebrundic  staff   1770 Sep  4 12:48 memory.x
drwxr-sr-x@   3 ebrundic  staff    102 Jul  1 12:06 nousb
-rw-r--r--@   1 ebrundic  staff  15817 Mar 21 21:07 periph.x
wmmit032091:msp430f5529 ebrundic$ ls -l nousb/
total 8
-rw-r--r--@ 1 ebrundic  staff  1770 Mar 21 21:07 memory.x

Saving the original memory.x somewhere and copying nousb/memory.x into the main (msp430f5529/memory.x) file, it gives me access to that extra 2KB.

USB version:

MEMORY {
  sfr              : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */
  peripheral_8bit  : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */
  peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */
  bsl              : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */
  infomem          : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */
  infod            : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */
  infoc            : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */
  infob            : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */
  infoa            : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */
  usbram (wx)      : ORIGIN = 0x1c00, LENGTH = 0x0800 /* END=0x2400, size 2K */
  ram (wx)         : ORIGIN = 0x2400, LENGTH = 0x2000 /* END=0x4400, size 8K */
  rom (rx)         : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */
  vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */
  far_rom          : ORIGIN = 0x00010000, LENGTH = 0x00014400 /* END=0x00024400, size 81K */
  /* Remaining banks are absent */
  ram2 (wx)        : ORIGIN = 0x0000, LENGTH = 0x0000
  ram_mirror (wx)  : ORIGIN = 0x0000, LENGTH = 0x0000
  signature        : ORIGIN = 0x0000, LENGTH = 0x0000
}
REGION_ALIAS("REGION_TEXT", rom);
REGION_ALIAS("REGION_DATA", ram);
REGION_ALIAS("REGION_FAR_ROM", far_rom); /* Legacy name, no longer used */
REGION_ALIAS("REGION_FAR_TEXT", far_rom);
REGION_ALIAS("REGION_FAR_DATA", ram2);
PROVIDE (__info_segment_size = 0x80);
PROVIDE (__infod = 0x1800);
PROVIDE (__infoc = 0x1880);
PROVIDE (__infob = 0x1900);
PROVIDE (__infoa = 0x1980);

Nousb version:

MEMORY {
  sfr              : ORIGIN = 0x0000, LENGTH = 0x0010 /* END=0x0010, size 16 */
  peripheral_8bit  : ORIGIN = 0x0010, LENGTH = 0x00f0 /* END=0x0100, size 240 */
  peripheral_16bit : ORIGIN = 0x0100, LENGTH = 0x0100 /* END=0x0200, size 256 */
  bsl              : ORIGIN = 0x1000, LENGTH = 0x0800 /* END=0x1800, size 2K as 4 512-byte segments */
  infomem          : ORIGIN = 0x1800, LENGTH = 0x0200 /* END=0x1a00, size 512 as 4 128-byte segments */
  infod            : ORIGIN = 0x1800, LENGTH = 0x0080 /* END=0x1880, size 128 */
  infoc            : ORIGIN = 0x1880, LENGTH = 0x0080 /* END=0x1900, size 128 */
  infob            : ORIGIN = 0x1900, LENGTH = 0x0080 /* END=0x1980, size 128 */
  infoa            : ORIGIN = 0x1980, LENGTH = 0x0080 /* END=0x1a00, size 128 */
  ram (wx)         : ORIGIN = 0x1c00, LENGTH = 0x2800 /* END=0x4400, size 10K */
  rom (rx)         : ORIGIN = 0x4400, LENGTH = 0xbb80 /* END=0xff80, size 48000 */
  vectors          : ORIGIN = 0xff80, LENGTH = 0x0080 /* END=0x10000, size 128 as 64 2-byte segments */
  far_rom          : ORIGIN = 0x00010000, LENGTH = 0x00014400 /* END=0x00024400, size 81K */
  /* Remaining banks are absent */
  ram2 (wx)        : ORIGIN = 0x0000, LENGTH = 0x0000
  ram_mirror (wx)  : ORIGIN = 0x0000, LENGTH = 0x0000
  signature        : ORIGIN = 0x0000, LENGTH = 0x0000
  usbram (wx)      : ORIGIN = 0x0000, LENGTH = 0x0000
}
REGION_ALIAS("REGION_TEXT", rom);
REGION_ALIAS("REGION_DATA", ram);
REGION_ALIAS("REGION_FAR_ROM", far_rom); /* Legacy name, no longer used */
REGION_ALIAS("REGION_FAR_TEXT", far_rom);
REGION_ALIAS("REGION_FAR_DATA", ram2);
PROVIDE (__info_segment_size = 0x80);
PROVIDE (__infod = 0x1800);
PROVIDE (__infoc = 0x1880);
PROVIDE (__infob = 0x1900);
PROVIDE (__infoa = 0x1980);

Not sure if there's an option to msp430-gcc that can force you to use the nousb/memory.x without manually overwriting the main memory.x file, I haven't figured it out yet.

 

10. The UART includes USCI_A0 on the boosterpack headers, and USCI_A1 connects to the backchannel UART.  So now you can have your cake & eat it too... a GPS boosterpack installed without interfering with your ability to play with backchannel UART comms.  Assuming you don't decide to whip out a USB serial link natively inside the chip, that is.

 

11. CCS still has a 16K flash code limit, but the idea seems to be that CCSv6 will contain the new RedHat GCC port added as an "unlimited code size" option.  It'll be interesting to see how this works out with the USB developer's package and MSP430Ware stuff that TI already has released for this chip.

 

12. Remember, F5xxx series have relatively long wakeup times in LPM3/LPM4 when the SVM is enabled I believe.  @@pabigot had a thread about this I think.

 

13. XT1 and XT2 are both soldered, XT2 has a 4MHz crystal (for accurate USB) and XT1 has your standard 32.768KHz XTAL.  Initializing an F5xxx series chip is substantially different from the value-line parts as to use the DCO you have to enable an FLL loop that "calibrates" the DCO.  I wrote a basic library to do this: https://github.com/spirilis/ucs_clockinit

 

Cool advantage of this, you can easily overclock the MSP430.  Past experiments with the MSP430F5172 taught me that it can run up to ~56MHz doing a very basic LED blink with __delay_cycles() before it started crashing :grin:

[bluehash 1,581]

@@spirilis That is awesome. Thanks for the review!

[cde 334]

Correct me if I am wrong, but if this is supposed to be a usb enabled host or otg device, where is the host/otg port?

[RobG 1,892]

13. XT1 and XT2 are both soldered, I believe XT2 has a 24MHz crystal...

 

Little correction, XT2 is 4MHz

[spirilis 1,265]

Also wanted to point out the details of the memory address space.

 

Product page: http://www.ti.com/product/msp430f5529

Datasheet: http://www.ti.com/lit/ds/symlink/msp430f5529.pdf

F5xxx / F6xxx User's Guide: http://www.ti.com/lit/ug/slau208m/slau208m.pdf

 

Memory map:

 

The MCU has roughly 47KB worth of flash available in the sub-64K address space.  0x4400 - 0xFFFF (with the last 128b or so being the interrupt vector table I believe).  Everything above that is contiguous.

 

There is 512b of Info_X memory, each page is 128b instead of 64b.

 

Also this one has 16-bit access to combined ports...

Port A = P1 & P2

Port B = P3 & P4

Port C = P5 & P6

Port D = P7 & P8

 

I'm not sure that any of these are contiguously available on the boosterpack layout, but if so they could be the basis of 16-bit parallel I/O particularly combined with the DMA controller.

[spirilis 1,265]

Correct me if I am wrong, but if this is supposed to be a usb enabled host or otg device, where is the host/otg port?

It's not host/OTG -- device-only.

Cool thing is that hub -- able to access the eZFET and the F5529's USB device functionality simultaneously with 1 port!