• Locked Locked
  • Replies 9 replies
  • Subscribers 81 subscribers
  • Views 15475 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP-FET430UIF firmware update problems, FET bricked, then resolved?

David Craig
Prodigy 40 points
Other Parts Discussed in Thread: MSP430FG4619, MSP-EXP430FR5739, MSP430F1612, MAX3232, MSP430F247, MSP-FET

Greetings,

I recently purchased a new MSP-FET430UIF version 1.4a as part of the MSP-FET430U40A bundle and had trouble using it in CCS v5.2. I was sure it had been bricked (through no fault of my own), but ultimately resurrected it and thought I would mention this to you members of the E2E community. I'm just starting out with the MSP30 line and perhaps this post will help others avoid the frustration I had to endure. It's always difficult starting out with a new platform, and you want to concentrate on your application, not the tools! Anyway, here's what happened.

When I started a debug session, CCS insisted that the firmware was out of date (on this brand new unit) and offered to upgrade. I proceeded through the various dialogs and the process seemed to be progressing, but got stuck at about 97% of the way through, with the dialog box showing "Updating Firmware: programming New Firmware...(TI MSP430 USB1/MSP430)(Cannot be canceled)". The process just hung, and after an hour or so, reluctantly, and fearing bricking the FET, I saw no option other than quitting CCS (it did quit OK, CCS itself was not hung).

I tried this a second time with the same results. One of the dialogs along the way says it's erasing the firmware. The red and green LED's where both dark throughout the process, except they were illuminated when I first plugged in the FET and before starting the "upgrade". I was sure the new unit was "bricked", and what a pain - RMAs, returns, dealing with my own company's red tape and purchasing department rules are just not worth it for an $80 item.

Yet, I wanted it to work. I hadn't done anything wrong, just followed the on-screen prompts. I didn't unplug the FET while upgrading, nor have a power glitch, nor shut off my Windoze computer. It just didn't work for me. I tried upgrading CCS to version 5.3, the latest version, and a third attempt at updating the firmware failed. I was not instilled with confidence.

Finally, I sent a support email to TI and was surprised to have a real person contact me within a day. I had several email exchanges with  "Billy" and he suggested that I download TI's command line flasher. At first, I thought this tool was just a standalone tool for flashing a target device and Billy didn't understand the problem. But I finally took his advice and downloaded the MSP430 flasher CLI tool:

http://processors.wiki.ti.com/index.php/MSP430_Flasher_-_Command_Line_Programmer

Instructions about upgrading the FET firmware for this tool are vague. What firmware file was I supposed to point the tool to in order to upgrade the FET, and how did I tell CLI program that I was trying to update firmware on the FET itself and not a target device? I fiddled around a bit, and came to the conclusion that the firmware is built into the flasher or one of its components. After several attempts, I discovered that a minimal command line such as: MSP430Flasher.exe -n MSP430FG4619 was sufficient (pick any supported device since we're not really targeting a device, but the FET itself). The tool found the FET and said it's firmware was out of date (just like CCS did). I typed Y at the prompt to upgrade it. This got about 97% through the process...initializing, erasing, erasing, programming...97% and then FAILED just like in CCS! I really thought the FET was hosed.

But something did happen. The power light on the FET was thereafter illuminated, and Windoze detected a new device and went through it's automatic driver discovery and installation successfully. So I tried the same CLI command once again and this time the command ran successfully. Back in CCS 5.3, the debugger found the FET tool and now seemed happy, and flashed my target device with no problems. I could then run the program and set breakpoints through JTAG with my little ZIF breakout board.

Overall, a very frustrating experience that cost hours of time. Yet, in the end all is well.

TI's support was surprisingly good, in that there was a real human on the other end of the emails who was apologetic, sympathetic and helpful. But I would say that TI engineering has a lot of work to do in fixing this process. My computer is a relatively modern Dell T7500 workstation, lots of memory and disk space, running Windoze 7 64 bit, with vastly enough processing power to handle this simple upgrade task without a hiccup, and no problems with any other applications.

No one wants to spend time jumping through these kind of hoops to get up and running with a new processor. You just want things to work and not have to fiddle with the tools. You can see that TI is trying to provide low cost, simple tools to entice us to recommend their processors. Yet, this upgrade process is flawed and TI should reevaluate what's going on here, and provide a process that is as virtually "brick proof" as possible.

On another note, I have used the low cost MSP-EXP430FR5739 board with its built in USB FET tool and CCS, and that worked remarkably smoothly. My goal in purchasing and using the FET is to design my own, minimal MSP-430 controller circuit using an external programmer to flash and debug it. It seems the MSP-FET430UIF tool is the way to do that, and I was surprised to run into such difficulties considering that the low cost solution worked so well.

Oh, and by the way, although these discussions are helpful they can also be frustrating. Lot's of dead-end paths and twisty passages! In my searching it seems others have run into similar issues and the TI guy I was corresponding with admitted such. TI should get on it and address this problem ASAP to save the next poor guy the trouble. As helpful as "Billy" was, it's still my time that was being wasted, and there's nothing more valuable to me.

That's it, happy coding!

  • Guru 227245 points

    David,

    thank you for sharing your experience such a complete way (including links).

    Yes, the FET firmware has been a problem over th elast years.

    The MSp430F1612 on the FET is a (almost) standalone JTAG tool, providing a serial (!) API for the debugger. To do its work, teh FET needs to exactly know the MSP it has to program. Since the FETUIF is the tool for flashign all MSP430 devices, it needs a firmware update each time a new MSP430 is released. Usually, this firmware is provided by the CCS ro IAR version that also newly supports these devices. It isn't actually a requirement for working at all, ti is a requirement for supporting all devices supported by the compiler. If you work with a new compiler but an old device, you don't really need the firmware update.
    The limited FETs in the EXP boards only support a subset of all MSP devices, usually just those the EXp board was designed for, and therefore usually do not need a firmware update.

    David Craig said:
    My computer is a relatively modern Dell T7500 workstation

    'relatively modern', in conjunciton with Win7/64, is likely part of the problem.

    The firmware update itself is a complicated process. As I said, the API is a serial API. The FET is accesed through a TUSB USB->ser converter. Now USB has different timings than a real physical COM port. The newer the OS, the more and more complex layers of USB drivers are between the software and the FET. Up to the point where some things won't work as they are assumed to do, and the upgrade mechanism 'hangs'. (the firmware update is more than just a serial connection. Here the timing of commands and RTS/CTS signals is important.)

    Win7/64 is especially fragile regarding USB drivers and timing-critical applications. It's a good idea to do updates like this on XP/32.

    David Craig said:
    CCS insisted that the firmware was out of date (on this brand new unit)

    Well, even on a brand new unit, its production date may be before (if only by days) the latest compiler version.
    Also, there's another thing: from CCS4 to CCS5, the API has changed. Some software requires the old API, latest CCS and IAR require the new one (and therefore require an update) while others (liek teh Elprotronic software) accepts both.
    In addition, the firmware of the TUSB chip and the windows drivers have undergone some changes too, The original setup was using a VCP (virtual com port) driver, while new a CDC driver model is favored. However, older tools still require the VCP, so the FET is delivered with the latest still abckwards compatible firmware and gets updated when you actually start to use it with a new CCS or IAR version (making it incompatible to tools requiring the older API and driver model)

    I agree that all this is a bit inconvenient and (in your case) more than in most other cases. However, an out-of-the-box solution would also mean limitations. The FETUIF is meant as usinversal tool. One device for all MSPs. To be that flexible, some things need to be less convenient than one might wish. (in contrast to the limited FETs on the experimenters boards). but that means you don't have to buy multiple FETs for multiple MSPs. :)

  • in reply to Jens-Michael Gross
    Prodigy 40 points

    Jens-Michael

    Thanks for the reply and clarification. It was not clear to me that the FET had to know about every device it can program, nor that the firmware update could be skipped. I figured it was a more generic process. I'm not sure I remember seeing an option to skip the update when CCS said the update was needed, but in any case, I would have gone ahead with update anyway expecting it to work without a hitch. An easy to read tutorial about the FET might be a useful addition to your documentation. The hardware tools document is so homogenized with all of the different socket board modules that it's difficult to read, and short on information specifically about the FET and how it works.

    As for your comment about the API being a serial interface - this just makes me long for the days when we only had to worry about getting the connections of the TxD, RxD and hanshake lines of our serial ports correct. I'm not sure I see any great advantage to a USB interface for a device such as the FET. Perhaps, a serial implementation would be worthwhile, or it would be worth considering the the parallel port version.

    And speaking of Windoze (and a bit off topic) I would love to see some support for the Macintosh. I use Windoze only because I have to for tasks such as this, not because I want to. If I could use my Macintosh (natively) for development I would definitely do so. And now, with CCS based on Eclipse, it seems that drivers for the FET would be the last hurdle to cross-platform compatibility.

    No matter, the FET430UIF is working now and I appreciate your support. I wish I could be an expert about all the different processors that are available to me, but there are too many choices and they all have their quirks. Of course, it's the low power features that I'm after in the MSP430 line at the moment. I do appreciate that TI provides inexpensive and easily available start up tools. The tools matter almost more than the device itself does, given that there are so many good choices of microcontrollers out there.

    Thanks again, Dave

  • in reply to David Craig
    Guru 227245 points

    David Craig said:
    I'm not sure I remember seeing an option to skip the update when CCS said the update was needed

    Well, if the FET has a firmware that is compatible with V2 DLL (Which is , I think, the default), and the IDE uses V3 DLL API, then the update is mandatory. But I think you'll still be able to cancel the update (if not, disconnect the FET before preoceeding), to maintain the old API for tools that might still need it. However, this means you cannot debug with this one (and need two FETs then).

    David Craig said:
    I'm not sure I see any great advantage to a USB interface for a device such as the FET.

    Well, the advantage is that you can use it on todays PCs that do not have a real serial port anymore.
    Well, in theory, a serial FET and an optional USB/ser converter would have done the job as well, and people who still have real COM ports (like my developmend PC which has 4 and two parallel ports, added by two PCI cards) could benefit from the much smaller command latency. But since the FET also powers the target, and draws its supply form USB power...

    David Craig said:
    serial implementation would be worthwhile

    You shuld be able to cut the TUSB chip from the FETs MSP and instead apply a MAX3232, along with an external power supply.

    For my projects based on 1611 and 1232, I still use the LPT FET.

  • in reply to Jens-Michael Gross
    Intellectual 480 points

    Hi Jens-Michael,

    I had such problem too, unfortunately, I did not fully resolve it, may you have any suggestion for me.

    I used IAR 5.2 with msp-fet430uif and it was OK (the target is MSP430F247), also each start it shown message box advicing me to upgrade the firmware (may be because I have CCS 5.4 installed on the same PC). I had to use IAR 5.2 to provide support  for already developed project.

    I simple ignored this message.
    Yesterday I installed IAR 5.51 and agreed to upgrade the UIF.
    The procedure started but it seemed that it was not completed - progress bar stopped close to its end - exactly as David described.

    After some trials - installing / uninstalling different IAR versions, I succeeded to downgrade the UIF to v2 and now IAR 5.2 partially agree to work with the UIF - it initializes connection and starts software downloading, but at this point it crashes and closes the application with couple of messages like "memory can not be written",

    What can I do now?

  • in reply to RUBBI
    Guru 227245 points

    Sorry, I can't really help you here.

    Just some generic background info:

    The software acceses the FET through MSP430.DLL.
    There are two generally incompatible versions of MSP430.DLL, V2.x and V3.x. With the switch from V2 rto V3, the drivers for the FET have changed too from virtual COM port to CDC driver model. So once you upgraded the FET from V2 to V3, it is inaccessible for the PC until the new drivers have been loaded. This process may fail or require a reboot. It depends on your generic USB drivers (dependent on your USB controller).

    Now each revision of MSP430.DLL comes with its own istance of the FET firmware, so the FET firmware perfectly matches the DLL.
    Now each compiler come swith its own version of MSP430.DLL. THis is why you get asked to update: the current FET firmware doesn't match the version of the currently used MSP430.DLL.
    YOu may refuse to update. Chances are, that it will work anyway, iof the changes are too small to have a negative effect. Or you use the same instance of MSP430.DLL in all installed compilers (which will work as long as there is not too much difference in the functionality - a newer DLL will more likely work with an older compiler than otherwise)

    However, the best is to have a separate FET for each compiler. And the compilers configured to only access the 'right' one.

    In your case, the partial working of IAR 5.2 seems to indicate that you downgraded to a FET version that is newer than 5.2 (so it doesn't offer you an upgrade) but no longer fully backwards compatible (hence the crash). But that's just a guess.

    I'm sorry, bu tI cannot have anysolution for you, just these information so you can keep trying. Personally, I'm not using CCS nor IAR, so I have (luckily) no personal experience with the problem, nor can I do own investigations on this field.

  • Prodigy 10 points

    Wow, what a great post....thanks man. You fixed both of my programmers! What a shame this sucked so bad :(

  • in reply to Jeff King1
    Prodigy 10 points

    This worked for me too! The first update failed, but the second one worked and now it seems to be in good condition! Thanks.

  • Prodigy 30 points
    Hello David. Thanks for such a great post. I am facing a similar problem. I have two debuggers. one is MSP-FET and other one is MSP-FET430UIF. I tried MSP430 Flasher tool in both the debuggers but i am getting Interface communication error. Is there any oher way to solve this issue. Thanks in advance.
  • in reply to Krishna Kinger
    Prodigy 40 points

    Krishna,

    Greetings. I'm glad you found the post helpful.

    It's been quite a while now since I first encountered the upgrade problem with my MSP-FET430UIF and wrote about it in this post. I must admit that since then all of these firmware updates succeeded without problems. Each time I've updated CCS I've gone through the firmware update for the MSP-FET430UIF by just following the prompts in CCS. It's all been good and I haven't needed to use the command line flasher since. (I've even used CCS and done a firmware update from my Macintosh using vmware!)

    So from my perspective, the initial problem was most untimely and unfortunate as I was just starting out!

    Now a couple of years later, I've had good results using the MSP430FR5793 in my own design and the TI hardware and software tools have been great. I've not tried using the newer MSP-FET tool.

    I'm sorry that I can't be of much help with your specific problem - the interface communications error. I would guess that the problem is just that - a communications error and is related to your cabling, computer or driver rather than either of the two debuggers. The only hint I can give you is to possibly check the device manager under devices and printers, to see if the tools are showing up on your usb bus when you plug them in.

    Perhaps one of the TI moderators can be more helpful.

    Good luck, Dave

**Attention** This is a public forum