MSP-FET430UIF: Firmware Upgrading

Paul,

if you are confident that the 1st UIF HW is faulty, you could send it back to us for a replacement.

Regards,

Dung

Yes, thanks Dung.  I am not much concerned about a return, the UIF h/w is definitely faulty - I have tried 3 PC - FET tool combos and it is the one variable that causes failure.  Any plans to put a hardware diagnostic in CCS?

I don't know if this applies to the problem, but it worked to bring back a wayward USB-FET in my case. 

I had a USB-FET that stopped working, after several months of no problems,  with single stepping broken.

CCE (2.0) had the pod connecting/erasing/reflashing the target just fine.

To do a reset, I disconnected the FET from the target and then disconnected the FET from USB.

Then I reconnected the FET, entered CCE-->Debug and single stepping was still broken.

However,  by forcing an update of the FET firmware, the FET was made usable again.

Here are the steps:

1. Exit CCE and disconnect the USB-FET from the target hardware, but leave the FET connected to USB.

2. Using the free Elprotronic-Lite FET-Pro430 go to "Tools-->MSP-FET430UIF Firmware Downloader"

    This downloads a new firmware image to the USB Pod

3. Then exit Elprotronic Lite, connect the pod to the target.

4. Bring up CCE and try to debug, in my case CCE didn't like the firmware version Elprotronic had flashed in the pod so it changed it to an older version it was happy with.

5. The result was single stepping WORKED again.

While  this isn't conclusive proof,  it does appear the Flash of the USB Pod's internal MSP430F1612 can get corrupted in such a way the Pod doesn't work correctly.

Note, if you have two good pods, you might want to open one of the pods, connect to the internal JTAG port of the internal MSP430F1612 and read, using Elprotronic, a known good F1612 flash image that you can restore if the Pod gets so confused normal updating, via USB, is not possible.

When I did this, with a very scrambled USB pod several years ago, I made a custom USB cable that only supplied +5v / gnd power to the target pod and also made a JTAG cable to the other other pod with an open Vcc  line.  The one row internal JTAG pins inside the pod are arranged in such a way that one row of a 2x7pin connector will connect correctly.

I didn't have the foresight to plan for this event, but I was fortunate enough to have access to three USB pods, two of which continued to work.

Of course, this applies only to those with at least two pods as you need one pod to read/re-flash the other..

I think John is right in some of the cases.

If the "hardware" is defective, of course it will not work and the firmware cannot be "updated"

But even if the "hardware" is perfect, it may not be able to "updated" the firmware the normal way and need to either use JTAG or BSL.

Latest update.

I went back to another project and single step was broken in the debugger..

This time I powered down my desktop computer and powered it back up.

Now the debug environment is working as expected.

My advice to force a rewriting of the USB pod's firmware may not be useful after all.

John Wright

Thanks John for that usefull description. My CCS 5.2 crashed during firmware update, and with your method I could re-flash the programmer.

Earlier I wrote:

>While  this isn't conclusive proof,  it does appear the Flash of the USB Pod's internal MSP430F1612 can get corrupted in such a way the Pod doesn't work correctly.

>Note, if you have two good pods, you might want to open one of the pods, connect to the internal JTAG port of the internal MSP430F1612 and read, using Elprotronic, a >known good F1612 flash image that you can restore if the Pod gets so confused normal updating, via USB, is not possible.

>When I did this, with a very scrambled USB pod several years ago, I made a custom USB cable that only supplied +5v / gnd power to the target pod and also made a >JTAG cable to the other other pod with an open Vcc  line.  The one row internal JTAG pins inside the pod are arranged in such a way that one row of a 2x7pin connector >will connect correctly.

>I didn't have the foresight to plan for this event, but I was fortunate enough to have access to three USB pods, two of which continued to work.

>Of course, this applies only to those with at least two pods as you need one pod to read/re-flash the other..

One co-worker killed a USB FET pod during a firmware upgrade so the "open the pod and reflash the internal MSP430F1612" method was tried again.

The main discovery was that early pods with a 5 pin internal header(HTDO, HTDI,HTMS,HTCK,GND)  ground pin 13 of their 14 pin jtag output connector while later pods  with a 7 pin internal (HTDO,HTDI, HTMS,HTCK,GND,RESET,VBUS)  header do NOT ground pin 13 of their 14 pin JTAG output connector.

A user attempting to reflash a USB-POD's internal 430F1612 using an early 5 pin internal header will find the 14 pin cable pin 13 will ground the VBUS (supply voltage) of the later pod's internal MSP430F1612 prohibiting re-flashing.

To be always able to program any pod with any other pod,  always open the 14pin cable line leading to pin 13 as I recommended in my earlier post (."JTAG cable to the other other pod with an open Vcc  line.")

This should not cause any problems in normal use with either the early or later pods as pin 13 is grounded in the 5 pin internal header early pods and a no-connect in later 7 pin internal header  pods.

Also a new tool that should work for reading/writing the pod's MSP4301612 flash is the TI "MSP430 Flasher" command line programmer, so one is not limited to the Elprotronic tool.

We did not try the TI MSP430 Flasher and elected to use the Elprotronic tool as before.

The pod came back to life.