Jump to content
Sign in to follow this  
fluffy

MSP430 support for 430FR (FRAM) parts?

Recommended Posts

Couldn't find anything in a quick Google, nor in a search of this board. Anyone know if/when the new FRAM 430 parts, such as the one on the MSP-EXP430FR5739 dev board will be supported by mspgcc under Linux?

 

Thanks.

Share this post


Link to post
Share on other sites

I don't know if they hang out here or not.

 

It's probably best to contact the mspgcc crew directly at their website.

 

Also, the TI.com/fram site says that there are no stock on the FR5739 yet.

 

And, in the MSP-EXP430FR5739 box contains a waiver form that declares the FR5739 an Experimental Product. That means that they won't let anyone have production quantities of the device without signing this waiver. It's not completely characterized and tested yet.

 

So, I think that the mspgcc crew are probably going to have to buy one of these FRAM boards and do the work.

Share this post


Link to post
Share on other sites
Couldn't find anything in a quick Google, nor in a search of this board. Anyone know if/when the new FRAM 430 parts, such as the one on the MSP-EXP430FR5739 dev board will be supported by mspgcc under Linux?

 

Thanks.

 

 

It looks like the uniarch version of mspgcc has headder files for it. Unfortunately, mspdebug doesn't support it yet and I have not had a chance to see if I can get it to work.

Share this post


Link to post
Share on other sites

I've got one of the MSP430FR5739 experimenter boards and have been trying to get mspdebug working on it.

(mspgcc seems to work fine for this part, though I haven't tested the result)

Currently I can run the program and get possibly correct register outputs, but programming doesn't work yet.

Attached are some usb sniffs from code composer studio talking to the chip, if that helps anyone.

I also sent this to the guy who wrote mspdebug, and have heard of other people contacting him, so maybe he'll get around to adding this soon.

usblog.zip

Share this post


Link to post
Share on other sites

I have also had luck compiling a simple program with the new header files.

 

I've tried mspdebug with the "--force-fet-id" option. This seems to work but the program memory start address is different than a few of the chips I've tried. I've tried to look at the datasheet but I'm getting errors on the TI site. Not sure if it's just temporarily down or something else. I managed to burn up the demo program by trying to write to it, so it appears that I've at least done *something*... Not that I am suggesting that someone else do the same, but it appears that it is at least possible to initialize FET on this board. I'm out of time to hack on it for the night though.

Share this post


Link to post
Share on other sites

zborgerd, I got the same results. It blows away the code on there when trying to erase. I wonder if maybe it's erasing correctly, but mspdebug doesn't handle the response from the fet properly.

 

Daniel Beer, the maintainer of mspdebug sent me a patch to test, but it didn't really seem to make any difference over using the --force-fet-id option. I guess well see what he comes up with next.

Share this post


Link to post
Share on other sites
zborgerd, I got the same results. It blows away the code on there when trying to erase. I wonder if maybe it's erasing correctly, but mspdebug doesn't handle the response from the fet properly.

 

Daniel Beer, the maintainer of mspdebug sent me a patch to test, but it didn't really seem to make any difference over using the --force-fet-id option. I guess well see what he comes up with next.

 

 

It seems to be erasing at least part of the old program. I wanted to dig back into it today but didn't get a chance. I'm hoping to be able to try it out this weekend. I'd love to get my hands on the patch. Is it just a modification to fet_db.c? Does the debugger fire up and ID it correctly (in spite of the write failure)?

Share this post


Link to post
Share on other sites

Very good guys. I've got the FRAM dev board too and was just fiddling around trying to get gcc to work. Any updates are greatly appreciated.

 

By the way, I assume you are using the June 12, 2011 (20110612) version of the compiler, right?

Share this post


Link to post
Share on other sites

Took some time off from my networking toys to pull my Framinator or Fraunchpad

out of its box. I got the the latest MSPGCC and MSPDEBUG compiled and woiking

on my Linux laptop. I are one happy camper! vim+make+compiler and I be happy!!!

A big Texas THANK YOU for those involved! 'preciate it!

 

-Rusty-

Share this post


Link to post
Share on other sites

Great! It looks like I was just a couple of days ahead of this. Daniel Beer updated the mspdebug repo with support for the 5739 shortly after I posted.

 

Anyway, I can't wait to get this thing up and running. I guess its worth noting for those like me who are new to the 430 line and its GCC toolchain, the best place to get mspdebug is probably Beer's page. I spent quite a bit of time fiddling around with outdated versions before I went straight to the source.

Share this post


Link to post
Share on other sites

There was a bug in the new version of mspdebug on ubuntu where the cdc-acm driver would interfiere. This was fixed in the latest git(a5def5cf92c96b286024a72cdf24c814530373ac).

 

So i got to program the board, but it doesn't seem to work. I tried turning on the leds from P3.

Anyone know what's wrong with this code?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...