On Tue, Sep 07, 2010 at 09:03:08PM -0400, Kim Toms wrote:
> Thanks for the suggestions. Here's the results.
>
> I downloaded the binary package as described, and installed also as
> described. For some reason I couldn't get Filer to browse to the directory
> containing the Info.plist file, and when I opened it with the property list
> editor, I could not save the file, in spite of being root. So, I used
> trusty old vi to do the editing.
>
> I was able to plug in an eZ430-F2013 and connect to it with mspdebug; the
> default program it was running (flashes LED) instantly stopped, and when I
> typed 'run' it continued (to flash). Experience with the MSP-FET430UIF was
> not so successfull.
>
> The device node created for the eZ430-F2013 is named
> /dev/cu.MSP-FET430UIF620. The device node created when the MSP-FET430UIF is
> plugged in is /dev/cu.MSP-FET430UIF410. When I attempt to start mspdebug on
> the MSP-FET430UIF, I get the following output:
>
> MSPDebug version 0.10 - debugging tool for MSP430 MCUs
> Copyright (C) 2009, 2010 Daniel Beer <[email protected]>
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Trying to open UIF on /dev/cu.MSP-FET430UIF410...
> Initializing FET...
> FET protocol version is 20405003
> Configured for Spy-Bi-Wire
> Set Vcc: 3000 mV
> fet: FET returned error code 4 (Could not find device (or device not
> supported))
> fet: command C_IDENT1 failed
> fet: identify failed
>
> I have not yet looked at the source to see if I can figure out the problem.
>
> Later, it occured to me that I could try the JTAG mode. When I did, I was
> able to stop and start the system just like I was able to do with
> spy-bi-wire and the eZ430-F2013. I'm going to try loading a program (we
> tried, but the module was made wrong, so it didn't work, I found that
> problem after I got home). I also have an eZ430-RF2500 which I will try
> tomorrow.
>
> The CPU I'm using returns id info that is not listed in the fet-db; should I
> work on getting commit access to the repo, or send a diff to someone? I'm
> not sure of the meaning of all of the bits, so I can supply what's printed
> out as part of the error message, but it looks like there are 3 parts and
> what's in the other two is unknown to me (at least at this point).
Hi Kim,
You can send any information you can gather to me. If you send me:
(1) The name of the chip you're using.
(2) The name of a similar chip configuration which works
well-enough if you set --fet-force-id <name> (you can get a
list with --fet-list).
(3) The output when MSPDebug fails to identify (the lines labelled
"msg28_data:").
...then I should hopefully be able to cook something up which will
work. Alternatively, if you have access to IAR or similar on a machine
which you can run a USB sniffer on (like sniffusb 2.0), then I can
definitely get it working using the information logged when you
connect using the debugger.
Cheers,
Daniel
