Jump to content
JWoodrell

programming a MSP430G2955?

Recommended Posts

well if we have to fool it with a 3rd party tool chain, but it works for now that will be good, I am going to load the GCC tool chain, and MSPdebug, and see if I can make it play nice :).  I would ask @@paulpthcom if he used the launchpad as the programmer still, and just used the mspdebug to throw the code, or did he use some other programmer like the UIF from TI?

Share this post


Link to post
Share on other sites

I was just thinking if it would be possible if we ask Travis Goodspeed if we could make/license a 43oh version of the GoodFet and then have it assembled and sold through the Store at a low price. Should come to $10, max $15... I have no idea. I could send a cut of the proceeds over to him. This way we won't have to wait for a firmware update for the Launchpad.

 

What do you guys think about this? Does it easily integrate into CCS/IAR? How about environments.. Linux/MAC?

 

Adding @@JWoodrell, @@RobG, @@cde, @@oPossum, @@Rickta59, @@jazz

Share this post


Link to post
Share on other sites

well if we have to fool it with a 3rd party tool chain, but it works for now that will be good, I am going to load the GCC tool chain, and MSPdebug, and see if I can make it play nice :smile:.  I would ask @@paulpthcom if he used the launchpad as the programmer still, and just used the mspdebug to throw the code, or did he use some other programmer like the UIF from TI?

I used the launchpad as a SBW programmer, connected to a breadboard with the 2955 in a SSOP->DIP adapter and the minimum circuit required (caps on VCC/AVCC, pull up resistor and pull down cap on RST). Toolchain all hosted on a Mac, mspgcc and mspdebug, neither of which currently support the 2955. I told the compiler and mspdebug it was a msp430f2274 (not a msp430g2744, which is also not supported).

 

Pretty sure adding support for at least mspdebug and the new chips should be pretty easy, gcc would probably just involve a new header.

 

Feel free to ask any questions.

 

BTW unrelated but just noticed it https://www.olimex.com/Products/MSP430/Booster/MSP430-G2744BP/ is that new? Looks like they have the DIP packaged 2744.

Share this post


Link to post
Share on other sites

there is the hope right there, the launchpad CAN physically and electrically program the g2955 with its current firmware in place, it is just a matter of the software driving them.  CCS apparently is faulting cause i isn't happy, its not the launchpad kicking it back.

 

this is encouraging :)

Share this post


Link to post
Share on other sites

All MSP430 flash tools are based on defined table with all target devices description, something like (from Replicator source "Devices430.c"):

//                      TestPin      DataQuick      EnhVerify     SpyBiWire        RamEnd
//                Id       |    CpuX     |  FastFlash  |    JTAG     |    RamStart    |   MainStart
//                 |       |      |      |      |      |     |       |        |       |       |
/* F20xx */     { 0xF201, TRUE,  FALSE, TRUE , TRUE,  FALSE, TRUE , TRUE  , 0x0200, 0x027F, 0xF800 },
/*F21x1/2*/     { 0xF213, TRUE,  FALSE, TRUE , TRUE,  FALSE, TRUE , FALSE , 0x0200, 0x02FF, 0xE000 },
/*F22x2/4*/     { 0xF227, TRUE,  FALSE, TRUE , TRUE,  TRUE,  TRUE , TRUE  , 0x0200, 0x05FF, 0x8000 },
/* F23x0 */     { 0xF237, TRUE,  FALSE, TRUE , TRUE,  TRUE,  TRUE , FALSE , 0x0200, 0x09FF, 0x8000 },
...

 

With every new device, new line to description is added, and support is done. Let say, 10 minutes job.

Unfortunately, for TI lunchpad is completed board with integrated debugger/programmer and on board target chip. They don't see it as universal/separate tool for all MSP430G2xx devices, and don't won't to update it (now). With new MSP430G2955 launchpad it will come updated debugger/programmer.

 

Don't know if it is possible to force it to see MSP430G2955 as generic MSP430G2xx device, and flash it.

Share this post


Link to post
Share on other sites

the programmer side of the launchpad is the EZ430 programmer.  it just happens to be on the same board as the EXP430G2 target board.  they do view the EZ430 as a separate universal tool

Share this post


Link to post
Share on other sites

Pretty sure adding support for at least mspdebug and the new chips should be pretty easy, gcc would probably just involve a new header.

 

header files pabigot linked to a while back are not working ? Sorry no chips to toy with here, but it seemed to me that most, if not everything needed for mspgcc was included from the sourceforge link he gave.

 

As for mspdebug, it has an "unsupported" MCU feature built into it, 

Share this post


Link to post
Share on other sites

header files pabigot linked to a while back are not working ? Sorry no chips to toy with here, but it seemed to me that most, if not everything needed for mspgcc was included from the sourceforge link he gave.

I didn't see that link, will give it a try.

 

As for mspdebug, it has an "unsupported" MCU feature built into it, 

I didn't see that option in the man page, but I did go look over at the code a few minutes ago and looks like adding support for the new chips is basically 2 lines per device, mostly copy/paste. I'll probably give that a try as well.

Share this post


Link to post
Share on other sites

GoodFET uses it's own programming software. It does not do debugging.

 

No matter what programmer you have, there can always be problems with the latest chips. Give it a month or two and see what changes with TI's support.

 

Anyone desperate to program these chips right now without using a MSP-FET430UIF could probably do it using BSL and a FTDI FT231X or FT232R.

Share this post


Link to post
Share on other sites

I didn't see that link, will give it a try.

 

I didn't see that option in the man page, but I did go look over at the code a few minutes ago and looks like adding support for the new chips is basically 2 lines per device, mostly copy/paste. I'll probably give that a try as well.

 

I do not remember where I read it. Perhaps on the mspdebug FAQ page, but I do remember dbeer talking about this unsupported MCU feature. There may even be a post on these forums somewhere.

Share this post


Link to post
Share on other sites

I do not remember where I read it. Perhaps on the mspdebug FAQ page, but I do remember dbeer talking about this unsupported MCU feature. There may even be a post on these forums somewhere.

The FAQ http://mspdebug.sourceforge.net/faq.html just says to do what I did, looking at the code I don't see any way to say unsupported other than picking a chip.

Share this post


Link to post
Share on other sites

So looks like getting mspdebug to properly handle the 2955 is a bit more complex than just adding one extra line, there's a struct in fet_db.c that contains the data, some of its is just reported by the device, but looks like a good deal needs to be manually created and/or snooped via USB from some other device.

 

Below is my attempt at playing with it. The msg28_data just comes straight from the device. msg29_data looks like is a description of at least RAM/Flash amounts and who knows what else. No idea what map_2bdata is.

 

	{ /* Copied from MSP430G2452, with modifications */
		.name = "MSP430G2955",
		.msg28_data = {
			0x29, 0x55, 0x00, 0xa0, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x02, 0x02, 0x01, 0x00, 0x2a, 0xf7,
			0x00, 0x00
			/* extra: 89 00 00 00 00 00 00 00 */
		},
		.msg29_params = {0x00, 0x39, 0x31},
		.msg29_data = { /* Copied from MSP430G2452, with changes */
			0x00, 0x21, 0xff, 0xff, 0x00, 0x00, 0x00, 0x10,
			0xff, 0x10, 0x40, 0x00, 0x00, 0x11, 0xff, 0x20,
			0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x01, 0x00,
			0x01, 0x00, 0xd7, 0x60, 0x00, 0x00, 0x00, 0x00,
			0x08, 0x07, 0x10, 0x0e, 0xc4, 0x09, 0x70, 0x17,
			0x58, 0x1b, 0x01, 0x00, 0x03, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,
			0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x33, 0x0f, 0x1f, 0x0f,
			0xff, 0xff
		},
		.msg2b_len = 0x4a,
		.msg2b_data = { /* Copied from MSP430G2452 */
			0x00, 0x0c, 0xff, 0x0f, 0x00, 0x02, 0x02, 0x00,
			0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
			0x00, 0x00
		}
	},

Share this post


Link to post
Share on other sites

No matter what programmer you have, there can always be problems with the latest chips. Give it a month or two and see what changes with TI's support.

 

Anyone desperate to program these chips right now without using a MSP-FET430UIF could probably do it using BSL and a FTDI FT231X or FT232R.

 

You are right, but there is one programmer (unfortunately, at the moment, far from finishing stage) that will not be sensitive to future products at all. I am waiting for MSP430G2955 sample for testing, to be 100% sure.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×