MSP430F149: Using MSP-FET with BSLScripter's BSLDEMO2

I have no experience with MSP-FET, but some experience with BSLDEMO2, which was written for the serial port interface device described in Figure 6 of slau319.  I found that the polarity of the DTR output was the opposite of what works with more modern USB-to-serial adapters.  So you may want to look at whatever MSP-FET lines connect to the F149's /RST and TCK pins, and see if they look like figure 3 when you run BSLDEMO2.

But I have to say, I think the odds of your doing this whole thing succcessfully are very low, based on the description on your other thread here.  First, if you do manage to get BSLDEMO2 working, but get the password wrong, the BSL is going to mass erase the contents of the entire chip.  But even to get that far, you may have to deal with the issues involved with the BSL for this chip, including running the "Patch", depending on whether you have revision AA or not - see Table 16 and Sections 5.2 and 5.4.  It appears to be a can of worms.

In any case, I have modified the TI source code for BSLDEMO2 v2.01 to add the "+" option "i" which will invert the DTR line.  I compiled it using the LCC compiler, and as far as I can tell it works ok, but I've only tested it with a CP2102 USB-to-serial adapter connected to a G2553, not with an MSP-FET connected to an F149.  But I'd be happy to send you the .exe or the revised source, or both, if that will help.

Thank you very much for the advise and information. Basically what I want to do with this is to be able to confirm that I can put on a program and pull off successfully. I have a pretty big back story to this. I have a programmed part that is function correctly. I have a firmware file that is supposed to be the most up to date firmware. I am trying to prove or disprove that the firmware on the board is the same (or different) from what I have. When I program a different f149 with that firmware, it does not function how it's expected to. So I am trying to learn how to successfully pull off test firmware from a different controller and then test it on my programmed part with the password made from the firmware that I have. If it is pulled off successfully with that password, then that means that the firmware in the working part is the same as what I have in a TI-TXT format. then I can figure out that the firmware is not bad but something else it making my other chip not function correctly.

I am very sorry if that was hard to comprehend, this has been a long time project and I am just up against a wall with this step.