MSP-FET: Error connecting to the target: Unknown device

Hi Nathan,

On your custom PCB there should be a pull up resistor and cap on the RST/NMI pin on the MSP430F169.  Do you happen to know the values?

Hi Dennis,

According to the electrical diagram (found it !), there is a 10k pull up resistor on the RST pin. It seems there's no capacitor on this pin though.

Pull up resistor and cap combination on RST/NMI pin have impact on start-up and device running, but it is not related to (any) JTAG problem. Higher capacitance value (than recommended 1nF) can impact SBW because this pin is used for data transfer and clocking, but with JTAG it is not used.

I guess that UniFlash is configured to slowest JTAG speed by default, but you can check this to be sure.

It is also strange that setup that was working fine with old UIF is not working with new advanced (in any way) FET. And this is not the first topic that mention this, here on e2e.

Sorry this is the first time I'm working with UniFlash (and FETs). How do you set JTAG speed ?

Hi Nathan,

Ok, let me sync up here. You say the MSP-FET does work when using the Elprotronic software?

Nathan Alfano said:

Connect the MSP-FET to the board with another software (FET-Pro430 from Elprotronic), which works with the new FET but the software is not free and less user friendly than UniFlash

Yes, I can erase memory and flash with FET-Pro430. 

EDIT: it lets me check the firmware of both FET, the new one is v3.12.00.000, whereas the old one is 3.11.00.001.

Nathan,

When you try to update the firmware in FET-Pro430, do you receive an error message?

Hello Eddie,

There is no error message when I try to update the firmware. It goes to 85% in a second, then 100% and then it gets stuck on "Finishing ..."

I tried multiple times, the firmware is still 3.12.00.000.

Nathan,

It is strange that FET-Pro430 is working, but not Uniflash.  Could you also try using the Uniflash Cloud found below?  I am wondering if it could be some configuration in Uniflash.  When you use Uniflash, does it prompt you to update the MSP-FET firmware?

https://dev.ti.com/ 

Hi Eddie,

Sorry for the delay, end of previous week was a holiday. I tried with the cloud version of Uniflash, and the issue is the same. There is no firmware update prompt though.

Hi Nathan,

You might try to re-install the MSP430 FET drivers.  Here is a link to the download.

Once you re-install the drivers, follow the MSP-Flasher user guide (available from the same download link), section 5 for updating the MSP430 FET firmware.

Hi Dennis,

Thank you for the link, I reinstalled the FET drivers and MSP Flasher. I tried the procedure to update the FET but the flasher closes as soon as I press Enter.

EDIT: I get this message when I start MSP Flasher:

Second EDIT: I tried to launch the MSP430 example program in the same folder, and I get the following:

It says the FET firmware is up to date, even if it doesn't match the DLL version.

Hi Nathan,

Ok, the second screen shot looks promising, as it looks like MSP430 Flasher successfully programmed the target, correct?

If so, then if you try Uniflash again, it fails?

It looks like the target has been flashed successfully, the old program has been completely erased.

Then I tried with Uniflash again and it still produces the same error.

Hmmm....

It appears the problem has something to do with Uniflash.  Is there any reason why you can't use the MSP430 Flasher to program your devices instead of Uniflash?

It might sound dumb ... but I don't know how to use MSP430 Flasher.

If this is truly a problem, we will keep using the old FET with Uniflash for intern testing.

Hi Nathan,

That's fine.  Actually MSP430Flasher is a CLI or command line interface, so you send commands from the DOS prompt.  If you are just programming MSP430s over and over, this actually works out pretty nice when you use a batch file.

Here is the link to the users guide.  See page 6 for examples.  You can create a simple batch file that calls this command with all the parameters automatically, so you don't have to repeat typing the entire line.  If you need help with that, let me know.

MSP430Flasher can do other things, such as readout memory contents, program then start code execution, etc.

You're call.

Hi Dennis,

Thank you for this information. I tried to make a very basic .bat file, but I can't properly load the file into the device.

There is no error when I run it, but the the device doesn't work as expected:

Nathan,

If you program the target with the file fra.hex using the FET-Pro430 does it work?

Hi Dennis,

Yes, this is the file we use to program our boards. It works with FET-Pro430 (and Uniflash with the old FET).

Hi Nathan,

So in summary, you cannot get the new MSPFET working with either Uniflash or MSPFlasher, correct?

And the new MSPFET does work when you use FET-Pro430 software, correct?

Sounds like a driver issue.  Let me ask around to see if maybe it is possible to downgrade the FW version.

I believe there is something wrong with the .bat I made and MSPFlasher, since it doesn't work with the old FET as well.

EDIT: I found the big mistake in there. I used the -r trigger and it overwritten the original file (fra.hex). So I was loading the wrong program from the start with MSPFlasher.

I now get the following:

#Exit:59

#ERROR : file end error

2nd EDIT: From another thread with a similar issue, someone pointed out that the program file contained two end-of-file record lines and the last one could be removed:

I deleted the last line and it worked. I don't know what that last line is for and I don't want to delete anything if it can break something else. At least the MSP-FET works with MSPFlasher !

Hi Nathan,

Ok, thanks for sharing the good news.  So is you plan to use MSPFlasher instead of Uniflash?

Do you believe your issue has been resolved?

Hi Dennis,

I guess we will use MSPFlasher instead, yes. I'll just need to investigate why our .hex file has two end-of-file records.

Thank you for your patience and help !

Nathan,

How are you generating the .hex output file?

I am not. This is a file that we gave years ago to our electronic boards manufacturer, so they can load them before shipping. But we needed a way to load the boards ourselves for testing purposes.