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.

MSP430.DLL Problems?

Other Parts Discussed in Thread: ENERGIA

Hi all,

I'm working with a LaunchPad with the included G2231 and G2211 chips, and I'm experiencing the infamous "Error initializing emulator: Could not find MSP-FET430UIF on specified COM port" problem.  I'm running on a Windows 8 system using CCS 5.4.0.00091, using the drivers included with the package.  Here's what I've found:

  • The CCS debugger sometimes will connect to the board properly and run, but this is less than half the time.  Sometimes unplugging the board fixes the problem, sometimes not.  When it does work, it often takes several seconds to establish the connection.
  • MSP430Flasher seems to do better, but at some point will also lose connectivity with the LaunchPad, requiring the board to be unplugged and plugged back in again which usually (but not always) fixes the issue there.
  • Using the GDB proxy works about as often as CCS.
  • Rowley's CrossStudio for MSP-430 works *every* time, and connects almost instantly.
  • Device Manager shows a properly installed and working "MSP430 Application UART" device.
  • LaunchPadFirmwareUpdater2.0 seems to always find the LaunchPad, but almost always shows "No MSP430G2XXX device detected".  On the rare occasion where it does work, it indicates the firmware is up to date.
At this point, I'm inclined to believe there may be an issue with MSP430 DLL.  Everything I've tried that uses the DLL to communicate with the device has exhibited problems.  The one package that consistently works, CrossStudio, appears to use a proprietary DLL to talk to the USB device directly via the TI driver.  I've gone through as many posts on this issue as I can find, and tried all the troubleshooting steps (changing drivers, killing a variety of applications, swapping out the chip, etc.), to no avail.
Since the device itself appears to be working properly (as evidenced by a complete lack of issues with CrossStudio and working projects on my breadboard), does anyone have any suggestions?  I'm using an eval copy of CrossStudio, and $1500 for a commercial license of that product is a bit steep for functionality I should already have available.  Any ideas will be gratefully accepted.
  • it could be as well a problem with your USB drivers or the order in which drivers are loaded for other USB devices. The USB stack is quite complex and not really deterministic.

    The FET gets its instructions though an USB/serial bridge. And then carreis out these instructions through the JTAG connection. If the instructions are delayed by other USB bus activity (or just a high USB latency), it might be that the JTAG connection cannot be established properly.

    So try updating your USB drivers (for the USB controiller!) or (temporarily) remove othe rUSB devices or try a different USB connector.

    Also, you could try a different USB cable. A defective cable may cause dropouts and retry delays on the USB and leads to timing problems too.

  • Hi Jens-Michael,

    Thanks so much for taking the time to respond.  I had already taken the troubleshooting steps you suggested, although I just went through and tried them again, with the same results.  I have the latest drivers for the USB controller installed, and nothing else (except a keyboard and mouse) using the USB ports.

    This time I also looked a little deeper at what CrossStudio was doing, since it seems to be bulletproof in regards to working with the LaunchPad.  During a debug session I looked to see which file handles the CrossStudio process had open.  It did have the LaunchPad's USB serial device open, which implies that it's talking to the driver without issue, and since I can successfully debug code on the device, it seems the hardware itself is happy too.  I also had looked at the MSP430.DLL that Rowley provides, which appears to be a proprietary DLL that exposes a subset of the TI DLL's functionality (TI's DLL has 94 functions, and Rowley's a little more than a quarter of that).  To me, this would imply that either the TI DLL or whatever application is using it is the source of the problem, and since everything I've tried that uses the TI DLL (CCS, gdb-proxy, Energia, etc.) exhibits exactly the same problem, it seems most likely there's an issue within the DLL itself.  I've also found that if CCS gets itself into a bind with the LaunchPad, it usually will end up breaking things badly enough to where even CrossStudio can't talk to the serial device.  Unplugging & plugging in the LaunchPad fixes things for CrossStudio nicely, but the majority of the time CCS is still unable to establish a connection, even when MSP430Flasher is able to talk to the device.

    Thanks again for your time and suggestions.

  • Steve Preskitt said:
    since it seems to be bulletproof in regards to working with the LaunchPad.

    You have the LaunchPad disconnected while trying to use the FET?
    Maybe CCS is confused by the COm port used. Windows still has problems enumerating its OCM ports properly. There are (AFIAK) three different methods to do so and all of them have different limitations with properly enumerating all COM ports. Holes in the enumeration chain (e.g. COM6 exists, but not COM5), port number above 8 or 16 etc.

    Not to mention that por tnumbers may change when devices are hot-plugged and the COM number was auto-assigned.

    It seems that either CCS or the original MSP430LIB are a bit fragile with finding and using the correct COM port.
    You can try assigning a different (and fixed) COm port to the FET, and also configure this port for CCS (IIRC, there's a setting somewhere). Maybe you can get it to work this way.

  • Well, I found something that seems to work, although it's not a solution for everyone unless they have an MSDN subscription or an extra Windows license at their disposal, a relatively fast machine, and enough available memory.

    My issue was strictly with a LaunchPad - no FET was involved.  After setting a fixed com port for the device, I still was experiencing the same problems, and couldn't find any other process on the system that was using the device.  So, I fired up VirtualBox and ran a Win7 virtual machine with the TI device captured to the VM.  After unplugging and plugging in the LaunchPad, I found that CCS (running on the Win7 VM) can reliably talk to the LaunchPad and I can load and debug code on the MSP430.  In a similar manner I can route the LaunchPad device to a Linux VM and load and debug code using Eclipse, the mspgcc toolchain, and MSPDebug (since the LaunchPad is not supported in CCS under Linux).  Debugging is sketchy though, as the MSP port of gdb has problems correctly associating variables with the proper memory locations and thus often displays incorrect values for those variables.

    So, for the time being, I guess I will be using CCS in a VM.  Based on the advice of another poster, I ordered a separate Via-based USB card to see if that will allow me to run CCS natively on the Win8 host machine.  I'll let everyone know how that works out.

    Thanks again for your time and assistance Jens-Michael.  It's very much appreciated.

  • Update - as I mentioned in my previous post, I ordered a Via-based USB card (Rosewill RC-100).  It arrived today and I installed it in the machine, and after connecting the LaunchPad to it, the problems I was experiencing seem to have been resolved.  CCS can connect every time now (and much more quickly), and everything appears to be working properly - no VM required.

    So, for those LaunchPad users that have been experiencing similar problems, a $12 USB card might be the solution you're looking for.

**Attention** This is a public forum