John Porubek writes:
> Thanks for clearing this up for me and thanks also to JM for the
> additional clarification. I guess the older versions of FET firmware
> and IAR were shielding me from these issues, which is why I was
> confused now. But it all makes sense. Again, it seems so obvious in
> retrospect.
>
> > If you have a newer version of the firmware and MSPDebug doesn't
> > support your chip, sometimes you can get away with forcing the use of
> > a record for a chip which is close enough.
>
> This raises another question - how would I do this? Would I use the
> "--fet-force-id" flag? Would I follow this with the chip ID (e.g.
> '0xf227' for a MSP430F2274) that resides at 0x0FF0-0x0FF1 in the
> target device (also documented in "Features of the MSP430 Bootstrap
> Loader", slaa089d.pdf)? If so, boy was I way off base confusing this
> id with the FET protocol version!
>
> At this point these questions are mostly academic, since the chips I'm
> interested in are already supported. But inquiring minds want to know!
>
> I've been researching as I compose this message and I'm pretty sure
> I'm on the right track. Confirmation would be appreciated, though.
Hi John,
You use one of the chip names listed in the output of --fet-list, which
currently would be one of the following:
CC430F6137
MSP430F147
MSP430F148
MSP430F149
MSP430F1611
MSP430F169
MSP430F2013
MSP430F2132
MSP430F2274
MSP430F249
MSP430F2616
MSP430F5437A
MSP430F5438
MSP430F5438A
So, you might do something like:
mspdebug uif -d /dev/ttyUSB0 --fet-force-id MSP430F149
The chip names are not case-sensitive.
Cheers,
Daniel
