New MSP430F5529 USB Launchpad Released

[VaZso 3]

I have received mine yesterday.

 

As I would like to use it under Linux, I am disappointed.

Downloadable software for Linux does the same as the one for Windows - extracts the same softwares (mostly for Windows).

I feel it would be much simpler using a compressed file for both systems in this case...

 

I've wanted to try out the Python BSL updater tool under Linux, which has found the hardware, could erase the firmware, but instead of reprogramming it, I've got some error messages.

Also tried the same Python code using provided executable on Windows XP (although it is a virtualized system), but it did absolutely the same - so it found the hardware and I've got the same error message.

 

Anyway, I thought this USB BSL thing is the most interesting feature in the first round, but it seems there are no usable software for it yet, especially under Linux.

I almost forgot the torture setting up MSP430G2 under Linux, TI does not seems to be much more helpful for Linux users in this case... maybe a really bad choice for me.

 

Anyway, I hope things will be better on this side... or I should forget them.

[D^2 24]

Just looking at one random .c file, they're not doing any clock init because I assume they don't care... just letting the chip run at whatever speed it does out the door.  Not sure what that is, but I always init the clock.

It's always 1MHz at start up. It's convenient because it's the same across devices, and you don't have to do anything to make it work.

 

Start looking at the MSP430F55xx_UCS_*.c examples and you'll be slowly introduced to the rabbit hole.  One thing they seem to be leaving out is the Vcore voltage setting... that has to be raised to allow the CPU to run beyond certain frequencies.  My library sets it to the max (which must be done in a sequential and orderly manner) before setting up the FLL and DCO.

 

The code examples are usually pretty simple, showing you how to use one module at a time. It's probably worth checking out the driver library for these 'core' modules if you want to understand how to properly change the vcore & the clock settings. Or you can take a look at the Energia implementation in wiring.c (in the new version 000010). I'm posting the code here since energia hasn't rolled in the new update into the main Energia repository yet.

#if defined(__MSP430_HAS_UCS__)
     PMMCTL0_H = PMMPW_H;             // open PMM
	 SVSMLCTL &= ~SVSMLRRL_7;         // reset
	 PMMCTL0_L = PMMCOREV_0;          //
	 
	 PMMIFG &= ~(SVSMLDLYIFG|SVMLVLRIFG|SVMLIFG);  // clear flags
	 SVSMLCTL = (SVSMLCTL & ~SVSMLRRL_7) | SVSMLRRL_1;
	 while ((PMMIFG & SVSMLDLYIFG) == 0); // wait till settled
	 while ((PMMIFG & SVMLIFG) == 0); // wait for flag
	 PMMCTL0_L = (PMMCTL0_L & ~PMMCOREV_3) | PMMCOREV_1; // set VCore for lext Speed
	 while ((PMMIFG & SVMLVLRIFG) == 0);  // wait till level reached

	 PMMIFG &= ~(SVSMLDLYIFG|SVMLVLRIFG|SVMLIFG);  // clear flags
	 SVSMLCTL = (SVSMLCTL & ~SVSMLRRL_7) | SVSMLRRL_2;
	 while ((PMMIFG & SVSMLDLYIFG) == 0); // wait till settled
	 while ((PMMIFG & SVMLIFG) == 0); // wait for flag
	 PMMCTL0_L = (PMMCTL0_L & ~PMMCOREV_3) | PMMCOREV_2; // set VCore for lext Speed
	 while ((PMMIFG & SVMLVLRIFG) == 0);  // wait till level reached

	 PMMIFG &= ~(SVSMLDLYIFG|SVMLVLRIFG|SVMLIFG);  // clear flags
	 SVSMLCTL = (SVSMLCTL & ~SVSMLRRL_7) | SVSMLRRL_3;
	 while ((PMMIFG & SVSMLDLYIFG) == 0); // wait till settled
	 while ((PMMIFG & SVMLIFG) == 0); // wait for flag
	 PMMCTL0_L = (PMMCTL0_L & ~PMMCOREV_3) | PMMCOREV_3; // set VCore for lext Speed
	 while ((PMMIFG & SVMLVLRIFG) == 0);  // wait till level reached
	 
     PMMCTL0_H = 0;                   // lock PMM

     UCSCTL0 = 0;                     // set lowest Frequency
#if F_CPU >= 25000000L
     UCSCTL1 = DCORSEL_6;             //Range 6
     UCSCTL2 = 0x1176;                //Loop Control Setting
	 UCSCTL3 = SELREF__REFOCLK;       //REFO for FLL
	 UCSCTL4 = SELA__REFOCLK|SELM__DCOCLK|SELS__DCOCLK;  //Select clock sources
	 UCSCTL7 &= ~(0x07);               //Clear Fault flags
#elif F_CPU >= 24000000L
     UCSCTL1 = DCORSEL_6;             //Range 6
     UCSCTL2 = 0x116D;                //Loop Control Setting
	 UCSCTL3 = SELREF__REFOCLK;       //REFO for FLL
	 UCSCTL4 = SELA__REFOCLK|SELM__DCOCLK|SELS__DCOCLK;  //Select clock sources
	 UCSCTL7 &= ~(0x07);               //Clear Fault flags
#elif F_CPU >= 16000000L
     UCSCTL1 = DCORSEL_6;             //Range 6
     UCSCTL2 = 0x11E7;                //Loop Control Setting
	 UCSCTL3 = SELREF__REFOCLK;       //REFO for FLL
	 UCSCTL4 = SELA__REFOCLK|SELM__DCOCLKDIV|SELS__DCOCLKDIV;  //Select clock sources
	 UCSCTL7 &= ~(0x07);               //Clear Fault flags
#elif F_CPU >= 12000000L
     UCSCTL1 = DCORSEL_6;             //Range 6
     UCSCTL2 = 0x116D;                //Loop Control Setting
	 UCSCTL3 = SELREF__REFOCLK;       //REFO for FLL
	 UCSCTL4 = SELA__REFOCLK|SELM__DCOCLKDIV|SELS__DCOCLKDIV;  //Select clock sources
	 UCSCTL7 &= ~(0x07);               //Clear Fault flags
#elif F_CPU >= 8000000L
     UCSCTL1 = DCORSEL_5;             //Range 6
     UCSCTL2 = 0x10F3;                //Loop Control Setting
	 UCSCTL3 = SELREF__REFOCLK;       //REFO for FLL
	 UCSCTL4 = SELA__REFOCLK|SELM__DCOCLKDIV|SELS__DCOCLKDIV;  //Select clock sources
	 UCSCTL7 &= ~(0x07);               //Clear Fault flags
#elif F_CPU >= 1000000L
     UCSCTL1 = DCORSEL_2;             //Range 6
     UCSCTL2 = 0x101D;                //Loop Control Setting
	 UCSCTL3 = SELREF__REFOCLK;       //REFO for FLL
	 UCSCTL4 = SELA__REFOCLK|SELM__DCOCLKDIV|SELS__DCOCLKDIV;  //Select clock sources
	 UCSCTL7 &= ~(0x07);               //Clear Fault flags
#else
        #warning No Suitable Frequency found!
#endif
#endif // __MSP430_HAS_UCS__

[RobG 1,892]

Here's another clock setup example with 2 settings, 4MHz (XT2) and 25MHz (DCO/REFO)

#include <msp430.h> 

void setUpClock();
void setVcoreLevel(int level);

/*
 * main.c
 */
int main(void) {
	WDTCTL = WDTPW | WDTHOLD;	// Stop watchdog timer

	setUpClock();

	while (1)
		;

}

void setUpClock() {

	setVcoreLevel(0x01);
	setVcoreLevel(0x02);
	setVcoreLevel(0x03);

///// 4MHz XT2 /////////////////////////////////////
//
//	P5SEL |= BIT2 + BIT3; // Port select XT2
//
//	UCSCTL6 &= ~XT2OFF; // Enable XT2
//	UCSCTL3 |= SELREF_2;
//	UCSCTL4 |= SELA_2; // ACLK = REFO, SMCLK = DCO, MCLK = DCO
//
//	do {
//		UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
//		SFRIFG1 &= ~OFIFG;
//	} while (SFRIFG1 & OFIFG);
//
//	UCSCTL6 &= ~XT2DRIVE0;
//	UCSCTL4 |= SELS_5 + SELM_5; // SMCLK = MCLK = XT2
//
/////////////////////////////////////////////////////

///// 25MHz DCO REFO ////////////////////////////////
//
//	UCSCTL3 = SELREF_2; // Set DCO FLL reference = REFO
//	UCSCTL4 |= SELA_2; // Set ACLK = REFO
//
//	__bis_SR_register(SCG0);
//	UCSCTL0 = 0x0000;
//	UCSCTL1 = DCORSEL_7; // 50MHz operation
//	UCSCTL2 = FLLD_0 + 762;	// (N + 1) * FLLRef = Fdco, (762 + 1) * 32768 = 25MHz, FLL Div = fDCOCLK/2
//	__bic_SR_register(SCG0);
//	__delay_cycles(782000);	// 32 x 32 x 25 MHz / 32,768 Hz ~ 780k MCLK cycles for DCO to settle
//
//	do {
//		UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + DCOFFG);
//		SFRIFG1 &= ~OFIFG;
//	} while (SFRIFG1 & OFIFG);
//
////////////////////////////////////////////////////

}

void setVcoreLevel(int level) {

	PMMCTL0_H = PMMPW_H; // Open PMM registers for write
	SVSMHCTL = SVSHE + SVSHRVL0 * level + SVMHE + SVSMHRRL0 * level; // Set SVS/SVM high side new level
	SVSMLCTL = SVSLE + SVMLE + SVSMLRRL0 * level; // Set SVM low side to new level
	while ((PMMIFG & SVSMLDLYIFG)== 0);	// Wait till SVM is settled
	PMMIFG &= ~(SVMLVLRIFG + SVMLIFG); // Clear already set flags
	PMMCTL0_L = PMMCOREV0 * level; // Set VCore to new level
	if ((PMMIFG & SVMLIFG))
		while ((PMMIFG & SVMLVLRIFG)== 0); // Wait till new level reached
	SVSMLCTL = SVSLE + SVSLRVL0 * level + SVMLE + SVSMLRRL0 * level; // Set SVS/SVM low side to new level
	PMMCTL0_H = 0x00; // Lock PMM registers for write access
}

[Automate 69]

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:

 

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.

 

Which board rev did you get to advance test?

 

I noticed a picture from MF that is rev 1.2 http://ow.ly/i/3deJn/original but the image here at 43oh is 1.4 http://www.43oh.com/2013/09/ti-releases-new-msp430f5529-usb-launchpad-for-12-99/

 

Everyone who has received theirs from the TI store have 1.4?

[abecedarian 330]

....

Everyone who has received theirs from the TI store have 1.4?

Mine ordered just after it went live is Rev 1.4.

[GeekDoc 226]

Which board rev did you get to advance test?

 

I noticed a picture from MF that is rev 1.2 http://ow.ly/i/3deJn/original but the image here at 43oh is 1.4 http://www.43oh.com/2013/09/ti-releases-new-msp430f5529-usb-launchpad-for-12-99/

 

Everyone who has received theirs from the TI store have 1.4?

 

My advance review board is v1.4.

[spirilis 1,265]

Ditto, mine is v1.4.

[VaZso 3]

Mine also rev 1.4

[jazz 209]

When TI published "msp430.dll" (MSP Debug stack) source code, if I remember right it was only for PC side, and not programmer firmware. Now, it is also programmer firmware as open source.

http://processors.wiki.ti.com/index.php/MSPDS_Open_Source_Package

 

This release supports the MSP-FET430UIF debugger, support for eZ430 emulators will follow later. MSP-FET430PIF emulators are not supported.

So, I will wait for EZ-FET lite, to see how it is done. Anyway, updating of MSP430F5529 LP firmware is over JTAG (not SBW), and it is possible only by MSP-FET430UIF (and maybe other JTAG tools). Don't understand why it is not possible by USB BSL or SBW.

 

http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSP430_ezFETLite/latest
"eZ-FET_lite_Release_Package_rev_1_10_20130712.zip" --- "eZ-FET lite Production Test Spec.pdf"

 

 

On MSP430F5529 LP, EZ-FET lite, everything is done by MSP430F5528 (same as MSP430F5529, but with less pins and different package). Guessing that is probably possible to flash standalone generic MSP430F5529 board (with 4 MHz XT2), and use it as LP.

And regarding USB-UART bridge, now it is fair enough, related to old LaunchPad (locked to 9600 bps).

 

Application ("backchannel UART") virtual COM port connection with the host, over USB, up to 1 Mbaud

[Fred 453]

Also noticed, linked from the product's wiki page, SLAU533 is the user's guide for the tool:  http://www.ti.com/lit/ug/slau533/slau533.pdf

 

Section 3 has detailed flowcharts and analysis of how the demo apps work; it's practically a primer on USB!

 

Wow. You're spot on. This new LP is great, but the USB stuff is a lot more complex than just playing around with a G2553. The guides and sample code help though.

 

My very simple first F5529 project will only require receiving some serial data. It'd be far easier to use a FT232 or even the existing UART backchannel on an original Launchpad - but where would be the fun in that?

[Fred 453]

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.

 

 

I just spotted this in the User Guide which may explain the behaviour:

 

Q: I'm trying to power the LaunchPad from a USB power supply (not an actual USB host), and it is not working. Does the LaunchPad not support this?

A: Unfortunately not. USB hubs shouldn't enable power to their downstream devices until the hubs themselves enumerate on the host, and that's what the TUSB2046 on the v1.4 F5529 LaunchPad does, through the power switches. If the hub never enumerates, power is not provided to the target F5529. Bypassing this might allow powering from USB power supplies but could interfere when operating with USB hosts.

 

Again, the benefit of the hub is single-cable development. Other power supplies can still be applied via the power header.

[spirilis 1,265]

I just spotted this in the User Guide which may explain the behaviour:

 

Yup, saw that too.  Guess it's not really getting fixed, so for "in the field" use we'll have to appropriate something else... I know someone made a Fuel boosterpack (not just @@bluehash 's LiPo bpak) which may work.  Guess I'll cross that bridge when I get to it.

[bluehash 1,581]

Yup, saw that too.  Guess it's not really getting fixed, so for "in the field" use we'll have to appropriate something else... I know someone made a Fuel boosterpack (not just @@bluehash 's LiPo bpak) which may work.  Guess I'll cross that bridge when I get to it.

Oh.. I totally forgot about that BP. Need to get back to it.

[rebeltaz 36]

So this isn't a(n easily) incorporated chip outside of the launchpad board itself, like the msp430g series? This is an SMD IC solderered directly to the board? I like the idea of using just the IC like the older 430g, I build my circuits around just that IC, but I can see using this for certain applications, I suppose.

[spirilis 1,265]

So this isn't a(n easily) incorporated chip outside of the launchpad board itself, like the msp430g series? This is an SMD IC solderered directly to the board? I like the idea of using just the IC like the older 430g, I build my circuits around just that IC, but I can see using this for certain applications, I suppose.

Unfortunately, no, it's a 0.5mm pitch 80-pin SMD chip. Not impossible of course, but I've never personally tried one. It's probably not as bad as you think but still not conducive to quick protoboard projects.

 

Sent from my Galaxy Note II with Tapatalk 4