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.

ez430-RF2500: MSP430 Application UART not reliably available

Other Parts Discussed in Thread: CC2500, TUSB3410

I've had my RF2500 kit for several weeks now.

In that time I have managed to work my way through the usual set of “new processor” basics: I've managed to convince the IAR Workbench to compile my C code and download it to the target board, and I've been able to successfully flash the LEDs and read the internal temperature sensor. On the other hand, I obviously still have a lot to learn: every time I read the F2274 documentation a new xxxCLK signal seems to have been added (Grin?).

One problem I've encountered has to do with the “MSP430 Application UART”, the MSWinXX driver interface to the F2274's specially-routed UART lines (P3.4, P3.5). Now, I can live with a 9600 Baud speed-invariant interface, but under some as-yet-undetermined circumstances it will completely disappear from Device Manager's list of available devices and only reappear after some serious effort on my part.

First, the equipment: I'm working from a Dell Latitude D630 laptop under MSWinXP SP2 (plus the usual random assortment of Microsoft-supplied “Install these or your system Will Suffer Unspeakable Horrors” patches). I'm using the IAR Embedded Workbench IDE 5.1.1.453.7838 (5.1.1.453), and I have attempted to access the target board's UART via USB under openSuSE Linux, but have had no success to date.

Hardware changes: I've soldered a 2x9 header onto the target board, and trimmed the “dongle” case to permit the modified target board to be plugged in.

Code: I have experienced the problem using the TI-supplied demo_AP.c code/file/project. I see the same problem using Hyperterminal or my own C# COMx port monitor. Unfortunately, I can't seem to reliably reproduce the problem.

It “feels” as if some part of the hardware/software inside the dongle is getting into a state where it won't reset itself after being reconnected. Of course, it could also be that the MSWinXP USB driver code is “holding on” to some characteristic of the hardware even when the dongle is unplugged, and then refusing to re-recognize it because it “knows” the port is busy.

Depending on the phase of the moon, one or more of the following steps seem to necessary to clear the problem:

  1. Unplugging and replugging the dongle.

  2. Cycling power on the laptop.

  3. (Drastic) Removing the target board and plugging in the empty dongle, then hot-plugging the target board into the dongle. I'm not comfortable doing this, and I _certainly_ wouldn't recommend it to anyone who was not already in desperate straits, but it does seem to work as a “last resort” when other options fail.

Has anyone else experienced this?

If so, can you offer any suggestions on how I could fix or work around it?

It's entirely possible that this is what IBM used to call a PUE in its S/360 APARS (Probable User Error), but even knowing that for certain would be useful. I'm also aware that I'm omitting three essential pieces of information in this posting... I just don't know what those are. (Sigh!)

My thanks for any insight anyone can provide on this problem.

 

Frank

 

  • I'm having problems too but mine are worse. The driver used to work fine with the old IAR and CCE v2; I uninstalled them and installed the latest IAR and CCE v3 and since them I can't download anything to the board anymore. I setup the FET Debugger in IAR to no avail. I uninstalled and reinstalled the driver many many times. I tried all the USB ports I have on this machine and nothing. All I get is Failed to initialize in both IAR and CCE.

    At least for you it works most of the time :-(  

    I think I'll give up and use an older computer which still has CCE v2 on it and it works fine.

      

  • What kind of error are you seeing? One quick thing to try: make sure you have the latest service pack available for CCE V3. This is a good first step to try and we just released a Service Pack 2: http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html#Support%20Software

  • I did install the SP2 a couple days ago so CCE is up to date. When I try Debug I get:

    Error initializing emulator:
    Could not initialize device interface

    I tried disconnecting the board to make sure at least CCE sees it when connected and in this case the error is below, different than one connected.

    Error initializing emulator:
    No USB FET was found

    I compared the debugger settings in CCE settings to a friend's of mine and they are the same and his works. I found some post in a forum saying the voltage might be a problem when board is powered externally but in my case power comes from USB so it should be fine. Unless somehow all the devices I have on USB make the voltage drop but then nothing would work on USB...

    Thanks for taking a look at my issue.

  • Did you ever get this problem resolved?

    I see exactly the same thing, when running the EZ430-2500 on my laptop, using CCE3 SP2. 

    However, when I run on my desktop (both systems use Vista, btw) everything works fine.  This is using the same EZ430 USB unit, and the same project settings.  And also, I have another PC running XP, which runs fine as well. 

    Not only that, but when I run on the problem laptop, I do see the EZ430 unit as a COM port, and can talk to the device with a terminal emulator.  So it's just the CCE software that's having a problem, and only on this PC.

    What's up with that??  Anyone?  Anyone?   ... Brandon?

    Thanks guys,    Sean

  • No, I didn't. It happened with both CCE3 and IAR so I gave up. I am using an older desktop I had around with XP and that works fine. Sorry for not being able to help.

  • Mmm, looks like I'll go your way on this.

    I tried what I could think of, but to no avail.  Would like to be able to use this tool on the (laptop) machine, which is what I intended it for when I bought it (!) but don't want to spend too much time working it.

    Thanks for you help though, appreciate the response !

    Sean

  • Quick update -

    With help from TI support (Billy), we identified the problem and got CCE to initialize and download the EZ430-RF2500.

    The problem was an apparent conflict with an HID device = the HP remote control for this laptop.  The solution was to open Control Panel, and uninstall the HID device.  When doing this, the EZ430 works fine.

    Note that every time I power up the laptop, the HP remote control HID reloads, so that the uninstall needs to be performed each time.  (This could be fixed but not a big deal, and means that in the event we want to use the remote control, it will still load automatically on power-up.)

    So, check this out if you're still having this problem; look at COM ports and HID devices, and remove anything unneeded that might conflict...

    Sean

  • It took me a while to try this again but I just did and it worked! Thanks a lot for following up and posting the solution.

    What fixed it for me was to remove one of the HID Keyboard devices under Keyboards in Device Manager (Win XP) - there were 2 of them, removing just one was fine.

    Again, thanks for your help!

  • Hi, I tried this to remedy a similiar problem under Vista, but still same error message could not find emulator. I removed the HID devices and allowed reinstall.

    Is there a permission's issue in Vista since CCE invokes the target server outside of its process space?

    TIA for any insight.

  • Brandon,

    I have seen this problem in Vista - Windows does not correctly typify the device during install in Vista and the "Could not initialize device interface" occurs when launching any debug. Is there an updated driver for the MSP 430 and CCE 3?

     

    Regards, Jerry Campbell

  • I've had this problem for as long as you guys have had; the application UART simply does not like being reseated. Take it out, and it won't install in Windows again. I was curious if any other developments had come about since the last post.

    I'm running WinXP SP2 on a Dell Precision 370. CCE build 3.2.2

    In my case, I've only ever gotten the UART to install on one specific USB port, one on my LCD monitor. It has never installed, if my memory serves me correctly, on any of the multitudes of USB ports on my tower (while of course, mass storage devices, mice, etc. will work just fine).

    I'm having the problem at the time of this writing, so I chose to switch the target boards (RF2500T) that I was using. To my amazement, Windows recognized the new target board (installed the application UART), but when I reseated the USB device, it would not reinstall the application UART. Now I have two target boards with dead application UARTs, although I suspect the problem will clear when I reboot.

    Also, I only have an HID mouse and no extra COM devices (just COM1 and LPT1), so I don't believe this is a conflict with those resources in my case. Yes, I did take out my mouse, but the application UART would not install then either.

    Any ideas would be well appreciated.

  • When you plug the eZ430-RF2500 into one of the USB ports that doesn't work, what do you see in the Windows Component Manager?

    Do you get a device shown with a yellow question mark?  This would mean that you need to reinstall the USB device driver again.

    I have seen the behavior I just described with other devices, EVMs, etc. and never really quite understood why the already USB device driver does not work for all ports.  There must be some subtle thing with the INF files that allows the same driver to be used on all USB ports, but I haven't placed my finger on it.

    Try that out.  I don't know for a fact if it will help, but I don't believe you have a damaged eZ430-RF2500.

  • I am experience some similar problems except that if I remove the eZ430-RF2500 from the USB port and plug it back in, the device is not even seen by windows.  Device manager does not show that the device is even there, I don't even get the device shown with the yellow exclamation mark.

    Every so often the device does connect and I get "USB Device Not Recognized."  which seems like the device is not being properly enumerated.  And if the planets are properly aligned and a butterfly flaps its wings on the other side of the globe, the device connects properly, which is the case right now.  I am currently just leaving it plugged in, but heaven forbid if I need to actually remove it for some reason.

    BTW, I am running Windows XP Pro, SP3, 4GB Ram and Dual Quad Core Xeon E5420 CPU.

     

    Regards,
    Clark

  • Sorry, I should have posted my end solution. My device was actually faulty, bad firmware. I got a replacement from TI and everything now works like a charm for any USB port I plug it in. I haven't had any problems since.

    Clark, your symptoms of unreliable connection/reconnection seem similar to mine, although I don't believe I ever received the "Device Not Recognized" message (maybe once?). Typically my device would either be recognized, or it wouldn't. Or it would be recognized, and upon reseating it, it wouldn't be recognized again until you rebooted Windows and performed a rain dance or two.

    I guess I have two suggestions for you from my experience, based upon the information you present. Check that the device behaves the same on other machines and not just yours (it was the same on other machines for me). If that's the case, I'd look into getting your hands on a new device.

    Of course, there are the "duh" suggestions like is the device showing it's being powered? LEDs lighting? But I bet you've already confirmed all that.

     

  • I still have problems every time I connect the ez430 to any USB port. What works for me though is to go *every time* to Device Manager > Keyboard and to remove the first HID Keyboard Device in the list. Unfortunately, sometimes this messes up my keyboard so then I have to unplug it and plug it back in but at least this way I can work with my ez board.

  • I'm getting this Failed to Initialize problem as well.  EZ430-RF2500 with CCE V3.1.  Works on my desktop, but will not work on my laptop.  I've gone through and disabled every HID device one at a time, but it still doesn't clear up whatever it is conflicting with.  Can you just Disable the conflicting driver, or do you have the uninstall?  I guess I'll try uninstall.

  • Add me to the list of  "Error initializing emulator: no USB....." when using my eX430-RF2500T, (v1.0). I've ran the uninstall, been through through reg removing all occurrences of Texas Instruments, and CCE, even removed the key
     HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\Vid_0451&Pid_f432
    and variations of. (This took some doing).
    Trashed "platform.xml", and run "eclipse.exe -clean", reinstalled CCE (22nd April 2009 edition). Which I think is enough to get some s/ware to run, and all fails.

    Am I missing anything?

     

    Yours Simon M.

    this is on a fully patched XP Pro machine

  • I am unable to run the demo reliably on my laptop. It starts fine sometimes, then times out within a few seconds (determined using portmonitor.exe from sysinternals)

    I find it interesting that this problem has not been fixed in the last 9 months.  This is the only usb device that does not work on my laptop.

    The fix is not to disable other devices (my touchpad fer instance).

    Every time I return to the settings menu, com1 is showing, don't know if this is normal or not.

  • I find it depressing! I wonder if the Bluetooth driver is messing with the com ports?

    Yours Simon M.

  • I too have intermittant device connection problems with a device recently purchased. Following the leads posted on this subject, I have found the following in my situation:

    WinXP Sp3.

    Davis Instruments Weather Station Vantage Pro II with data logger via USB that uses a Silicon Laboratories CP210x USB to UART Bridge Controller on COM5. Uses USB\VID_10C4&PID_EA60&MI_00\0001_00 Driver dated 2/22/2007 Ver 4.40.1.0

    Weather Station is set to run at startup and download data at 5 minute intervals. It sits sleeping except during download and data processing.

    Disconnecting the Weather Station USB Cable allows the EZ430-2500RF to be plug and Play detected every time.

    With the Weather Station USB connected, the RF is detected only occaisionally; Scan for Hardware Changes never seems to correct the problem.

    I need both of these devices connected correctly and reliably since they are both part of the system I am developing.

    Silicon Labs now has a Ver 5.40 Driver which I will test and report. Stay Tuned!

  • YES

    Silicon Laboratories CP210 Driver Ver 5.3.00 Cured the RF2500 P&P Detection Problem

  • But now it quit again. Found no UART driver in registry. (Don't think I intentionally deleted it!!)  Forced Found New Hardware to reinstall MSP430 UART but it Fails to Start Code 10. Tried both unregistered workbench UART and "certified" Code Composer Versions of UART with both getting Code 10 error.

  • I am still not able to reliably connect my EZ430-RF2500 device.

    But during problem analysis, I found a WDK Tool to view the EZ430-RF2500 Device replies during enumeration; USB Device Viewer  (UVCview.exe).

    Ran it during a failed enumeration and got two surprises (along with a better understanding of the enumeration process).

    1. The USB Device Viewer reports that the  MSP430 Debug-Interface has a bInterfaceClass:    0x03  -> HID Interface Class

       I can't understand why this EZ430-RF2500 device is declared as an HID Device.

      This might explain why some earlier posts on this thread have found HID conflicts.

    2. The USB 2.0 specs call for declaring one of three sets of descriptors; one for low/full speed, and two for High Speed devices.

       This is done with two fields; bDeviceProtocol field of the device descriptor, and the interface descriptor bInterfaceProtocol field.

     AS reported by USB Device Viewer and reviewing thespecs,  the Texas Instruments MSP-FET430UIF apparently has declared a new set of descriptors. They are apparently not following the USB 2.0 specs.

    Status. With my EZ430-RF2500 unable to reliably communicate to a Host PC, I can only implement the embedded control portion of my DAQ/Control project, I started with the EZ430-F2013 for Control; but I listened to the "siren's song" of the RF2500 radio and PC link. Now I am back to the F2013 waiting for TI to find why my RF2500 is unreliable. I think the RF2500 will ultimately be a very desirable device; I will try to be patient. 

    Does any "more driver knowledgable" forum contributor have any further ideas on the unreliable subject given these two findings?

     

  • One thing you might try is to use the older programmer board (from the ez430-2013) with the RF2500. You are supposed to be able to program 2013 boards on the newer programmer that comes with the ez430-RF2500, since the center pins are the same. SO maybe the other way around would work as well.

  • Fallingtrea,

    Yes I understand that is possible; part of my project expects to use a F2012 as an I2C RAM expansion when the host program is not running, so that portion of the F2012 flashing can use the EZ430-F2013 stick. If the EZ430-RF2500 is not reliable in time for use flashing the AP/ED boards, then I will try using the EZ430-F2013 stick for that.

     But I need the USB in the AP/RF2500 to be able to reliably talk to the Host PC via USB for the Data Acquistion portion of my project. So far this is a hit-or-miss proposition. Until this becomes reliable, I am forced to not being able to use the AP/CC2500/USB capabilities for any useful project purpose.

    Thanks for your input.

  • Well if Microsoft can use an apparent conflicting bDeviceProtocol and BInterfaceProtocol (0,2 resp) for their "Microsoft Wireless Optical Desktop® 1.00; then TI's conflict (0,1 resp) doesn't seem to be that far out in "left field".

    USB 2.0 defines only 0,0 and 1,1 and 1,2 (with an additional ,1) as the three speed definitions. Are their any addendums to the USB 2.0 specs that expand on this area?

    Why aren't these enumerations flagged as errors? Is it the "USB Device Viewer", a Microsoft product, that is reporting the incorrect values when they may be correct?

    It is only leading me to believe that USB, Enum's, and drivers are not a science.

  • [:)]While under further problem analysis for the unreliable EZ430-RF2500 USB enumeration, I tried to get an enumeration without any target board attached. The result was a consistent no enumeration. So it would be possible for my RF2500T AP board to be the cause. Tried the RF2500T ED board and it never failed to enumerate after many tries (probably over a dozen). So back to the AP board and it fails about 1 out of 3 tries. An intermittant AP board or a poor fitting Mini-Max connector. Can't find anything obvious with a 10 power loupe, either the connector or the AP board. Tried putting the AP board under thermal "shock". First at about 100F but still get about the same error rate as room temp. Tried an AP only cold temp of around 25F and it fails more often (the small thermal mass of the AP board makes it hard to avoid the cold soak "wearing off" quickly, thus making cold testing difficult); after going back to room temp the error rate returns to about the 1 out of 3 rate.

    I purchased the EZ430-RF2500 on 7/30/2009. I have added a header and a watch crystal to the ED board but have not modified the AP board or the Ez430 stick. Will TI still warrant it?[:)]

  • [:)][:(] The EZ430-RF2500 USB stick will not enumerate without a RF2500T target board, but the EZ430-F2013 USB stick will enumerate without a F21013T board.!

    Other than the EEPROM size and content, these two sticks seem to be identical.

    The EZ430-RF2500 did not enumerate with a F2013T board during testing.

    Conclusion; the EZ430-RF2500 requires a working SIN SOUT to be able to power up and set the enumeration (possible timing consideration?).

  • Further HID considerations and potential problems.[:(]

    Tried to review the sequence of events during my problem analysis by reviewing setupapi.log. Found an interesting effect that I think is un-intended.

    Found multiple installs for the problematic MSP430 Application UART that were successful. But though successful, I found that the GUID string was not consistant; looking closer I saw that the MSP430 driver that was successfully installed as an HID driver sometimes and sometimes as the correct Ports driver. A closer examination and some pondering leads me to conclude that if the driver was installed fully by either CCE or the EZ430-RF Sensor Monitor Demo, then the correct driver would be installed (at least some of the time). But if the driver install occurred during a Found New Hardware scenerio (I believe CCS V4.0 uses this method), then the driver installed is the best compatible driver that is found for the class of the device just pluggged in; because my EZ430-RF2500 USB stick enumerates with a bInterfaceClass of HID for the MSP430 Debug-Interface (which apparently mis-leads the driver install code), the search can not find the Ports driver and thus installs the generic HID driver. Even though the search is looking for the Vid/Pid of the stick, it ends up looking in the wrong place (had the search not been limited to the class, I believe it would have found the correct driver but thats not the way the code is currently written).

    And if you let Found New Hardware to allow Microsoft to search the web you can get a driver that is woefully out of date. When it gets installed as an oem.n.inf file then it gets included in the compatible driver list and can further confuse the issue if it gets to be the best driver!

    If you wrote a USB PC program that searches the Ports drivers looking for the MSP430.... driver, and it is currently a HID device; you will fail to find it! Is this possibly why the Sensor Monitor Demo does not search and instead requires you to play driver guide?

    [:)]Moral: The use of Explicit coding versus Implicit coding and installing seems to be the correct road to travel when working with the Windows Driver system. Letting Microsoft step in and do what he deems to be the correct thing is asking for troubles.[:(]

  • The USB interface that comes with the ez430-F2013 kit is wired differently from the USB interface that comes with the ez430-RF2500 kit. Mostly because of the secondary serial port. The Windows driver is also different because of the secondary serial port. So the code in the TUSB3410 is different between the two designs.

  • Im not sure if this is the appropriate area to report my problem. Please redirect me if not. I am working with the ez430rf2500 stick in addition to some 2012 target boards. I have been successful in downloading and debugging using IAR ver 4.1 /GUI 5.0 that came with the kits CD. After updating to the newer versions of CCS and IAR 4.2 I am no longer able to initialize my debugger.

    I am still able to return to IAR 4.1/GUI 5.0 and download and debug.

    I have been corresponding with IAR and have tried several different drivers, options in debugger options etc with no success. In the debugger options when I plug in the USB debugger I have the options of Automatic and an HID device. In IAR ver 4.1 its HID0 and in IAR ver 4.2 its HID0003. Both options still work in ver 4.1 but none will work with 4.2.

    I am unable to connect in CCE or CCS.

    In device manager the driver show up as version: 1.3.0.0 dated 12/11/2008.

    From what Ive been reading here I may need to disable one or more of my HID devices but am unsure which one. This is a Toshiba Tecra M4 Tablet with several HID devices. There are more than 1 of them using location 0 (the same location as the ez430 stick). Should I focus on these? Can I change these locations? Or is this even an issue?

    Thanks

    Bryant

  • Bryant,

    I think the driver for WinXP exhibits this problem, but the Win7 driver apparently does not. If you are thinking of going to Win7 then this might cause you to hasten that transition.

    If you have the EZ430-F2013 kit with its USB Stick, then you can download and debug the RF2500 boards with that. The difference between the 2 versions of the USB Sticks involves the addition of the UART TX/RX capability for the EZ430-RF2500 and it uses a set of drivers. The F2013 USB Stick only has one driver, different than the RF2500 set, which works for both types of boards when in download or debug modes..

    The HID conflict comes about because the EZ430-RF2500 USB Stick enumerates as an HID device; the reason for this is unknown to me since this device is not an interactive Human Interface Device. As a result of the HID enumeration, the PC causes the HID driver to be inserted in the chain of drivers for the device; thus unleashing the potential for HID device contention. 

    In a production mode, you are cautioned by TI to not use the EZ430-RF2500 as a base. Thus you should be looking at a UART capability with a USB interface. The F2274 and others in the line have native UART and other manufacturers have USB-UART interfaces that provide all the functions in a single chip.

  • First of all, I would like to point out that we are clearly all brave idiots for attempting to use ANYTHING from TI. It is clear from reading through this page that the folks at TI are absolutely clueless about this situation. Despite the original posting dating to 2008, TI has yet to provide an explanation or solution, other than the usual spread-the-blame-around.

    I am using CCS 4.1.0 on an XP SP3 machine (single processor, single core) with the ez430-RF2500 boards programmer/interface and target boards. I need the 'backchannel' serial port as part of my application, because I need the serial port - and I would really like it to work while running from the CCS debugger.

    I will dispense with the myriad bugs in CCS, and attempt to limit myself to the backchannel serial port. I have observed pretty much everything that everyone else described. Most notable is when the port appears (as COM14) in device manager, but nothing can open it - I have tried Hyperterminal and some other RS232 tools. Sysinternals PORTMON does not show any activity at the serial port level, so I think the problem is lower down - at the USB level. I have found NO particular procedure that actually results in correct operation of the serial port; it appears to be completely random.

    There are no other HID devices in the system. The mouse and keyboard use PS2 connector interfaces, and there is nothing else. HID interference is NOT the problem.

    I have even tried reinstalling the drivers from the TI supplied drivers from the USB_ez-rf directory, and that fails. I cannot really tell what is going on. The drivers use some very old Microsoft drivers - usbser.sys, which is quite old, and msports.dll, which is not even available on the Microsoft web site. anymore. So if there is a driver problem, I cannot really fix it, because the installation is so fragile it cannot be updated.

    Of interest here is that I CAN use other virtual USB ports, in particular one using FTDI hardware and drivers. FTDI uses serenum.sys, and works without problem.

    I will venture an educated guess that the enumeration process for the TI drivers is seriously flawed (that means it does not work deterministically) and that no one at TI even understands this. This means that despite selling USB interface MCUs, TI has no understanding of USB, and one would have to be an idiot to actually use one of their USB devices for anything. They clearly do NOT have a 'USB Solution'.

    My long term experience with TI 'support' is that I would be better off simply purchasing a jock strap.

  • Steve Kranish said:
    This means that despite selling USB interface MCUs, TI has no understanding of USB, and one would have to be an idiot to actually use one of their USB devices for anything. They clearly do NOT have a 'USB Solution'

    Well not being able to provide a failsafe USB driver forany PC/windows configuration out there does not mean that they don't have a clue about USB itself.
    Just no good understanding about hwo to implement the host side under Windows. And if I see all teh flakey stuff that even comes directly with windows and how many generations of USB-supporting Windows incarnations Microsoft neede to make it working at least most of the time in most cases (and yet there are still people having problems with standard HID devices in plain off-the-box windows installations), I'd say it's not TI to blame here.

    If you'd bought not only the MSP but also your PC and your OS from TI and then it isn't working, THEN you'd have a reason to complain. I guess you didn't. You want it to work on your possibly misconfigured, individualized and most likely by huindreds of installations and deinstallationds abused PC. That's a legitimate wish, but no base for a complaint. And surely no excuse for the tone of your post (especially the first and last sentence)

  • I have no trouble using an assortment of devices that use the FTDI serial <-> USB chips and FTDI drivers. THEY seem to understand the problem, and have a solid, consistent solution. No excuses about Windoze version, service pack, phase of the moon, or mystical incantations.

    The current (or whatever...) driver set for the backchannel serial port is so completely screwed up that when running, they consume 50% to 60% of the CPU via DPCs - which do not even show up in MS Task Manager - you have to use a better tool to actually see what is going on. The result is that the system simply comes to a halt. If you remove the drivers via Device Manager, all of a sudden you have your computer back!

    The problem here is that:

    TI does NOT fix things. This thread goes back to 2008, and TI has yet to offer any meaningful solution.

    TI does NOT provide meaningful support. I have been through this with MCUs, low power RF, TI-specific software to support proprietary products, etc. Simply getting a response from them is next to impossible.

    TI has gone to this 'social networking' support model in the wildly optimistic hope that their victims, oh excuse me, 'users' can help each other because they SURE cannot help anyone.

     

     

     

  • Steve Kranish said:
    I have no trouble using an assortment of devices that use the FTDI serial <-> USB chips and FTDI drivers.

    YOU don't. Others might. And then you do not understand why they have while you don't. Maybe you consider them stupid then? Hmm, maybe there are some people without problems with the TI stuff too. What do you think would they consider you?

    What you rant about TI can be said about almost everyone producing software or hardware. People need to try dozends of different video drivers for their popular ATI or NVIdia graphics card while others have no problems out-of-the-box. TV cards, soundcards, games, there are always a handful or more people who have problems and never get them solved by the manufacturer. I have been on both sides, the lucky and the unlucky one. But then, I cannot expect that everyone supports my personal computer configuration.

    The (perhaps majority) number of people who got it working will never show up in a forum.

    Steve Kranish said:
    TI does NOT fix things. This thread goes back to 2008, and TI has yet to offer any meaningful solution.

    If oyu had 2 years waiting for a solution, it cannot be something important.

    Steve Kranish said:
    TI does NOT provide meaningful support. I have been through this with MCUs, low power RF, TI-specific software to support proprietary products, etc. Simply getting a response from them is next to impossible.
    TI has gone to this 'social networking' support model in the wildly optimistic hope that their victims, oh excuse me, 'users' can help each other because they SURE cannot help anyone.


    So why are you still here, wasting your and our time?

  • Hi Steve,

    the eZ430 backchannel UART you are refering to is not supposed to be used in final products. The serial connection is software based and on top of the connection to the debugging interface. The UART backchannel is only supporting 9600bps and will not be working if the JTAG connection takes up all the ez430 emulator ressources. The backchannel should only be used for application development. Later on a true TUSB3410 connection with up to 460kbps should be used.

    Best Regards

    Eric

  • Thank you for your palinesque answer, not actually answering any of my questions, not offering a meaningful solution, and not adding any information beyond what has already been posted to this thread.

    I may have used the wrong term in describing my use of the backchannel serial port. I am currently working on a proof-of-concept prototype. For my current purposes, I need the serial port. For my final hardware, I do not need a serial or USB port at all.

    My system actually uses several ez430-RF2500 boards (it is a network, DUH!) Only one is connected to my PC via the emulator; the remainder use an FTDI 3.3V RS-232 to USB adapter cable - with surprisingly few problems. Only the one connected to the emulator is a problem....

    It would be nice if someone would describe exactly what is mean by the 'JTAG connection takes up all the ez430 emulator resources'. Like everything else related to CCS, it does not appear to actually be documented.

    The fact that a different USB implementation would provide faster access is meaningless; TI has proven beyond any reasonable doubt that they do not understand USB and cannot deliver a reliable implementation, so there is no possibility I would consider TI for such an application.

    This thread dates back to 2008. Other engineers have reported similar problems. TI has not offered any sort of solution, other than to concede that the serial/USB implementation on the ez430-RF2500 does not work very well. Ummm.. great. WHY should I trust you to make ANY of this work well?

    WHY does plugging in the USB connection from the ez430-RF2500 cause my computer to virtually stop, with more than 50% of CPU bandwidth devoted to DPCs? Do you even know what DPCs (deferred procedure calls) are?

    WHY do you use a java implementation that constantly pings the internet, and hangs the system while waiting for it to time out?

    WHY can't I find any meaningful help on the EXACT phrases found in the CCS menus?

    WHY is CCS non-deterministic? Sometimes when I do a 'Build All', it loads the hardware, ready for debugging.. and sometimes, it does NOT. Time of day? Phase of the moon?

    WHY, if this is based on open source software, CANNOT TI fix the stupid 'phase error' warnings about files being 2 seconds out of date? Some people have strict 'no warnings, no errors' rules on accepting source code, and it does NOT appear possible to do this with CCS. If TI is incapable of fixing this problem, how about making the 'open source' code available so someone else can fix it?

    WHY is CCS SOOOOOOOOOOOOO SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOW? Who thought that an interpreted IDE was a good idea? It takes MINUTES to do a rebuild and reload for a less than 16K application, and pretty obviously the compliler is NOT the problem.

     

  • Steve Kranish said:
    Thank you for your palinesque answer,

    Thank you for enrichening my vocabulary with a new, nice adjective.

    Steve Kranish said:
    not actually answering any of my questions, not offering a meaningful solution, and not adding any information

    Maybe it's just that you are not ready for the answers I have given and the information I have presented. Maybe some of it was obvious, yet it seems to be not obvious to you. Anyway I don't want to get banned from this board, so I won't be clearer.

    Steve Kranish said:
    Only the one connected to the emulator is a problem....

    No wonder. The connection through the emulator is only for internal purposes and done in a very specific way. And NOT intended for normal use. If you insist in using it despite of the fact that it is 'special' and then complain about it being 'special', well, that's your problem.

    Steve Kranish said:
    It would be nice if someone would describe exactly what is mean by the 'JTAG connection takes up all the ez430 emulator resources'.

    You have no clue what JTAG is, don't you? It is NOT a communications interface. It is a way to access the CPU, its registers and its memory space by intruding the normal operation of the CPU. Effectively the CPU is halted and its state is inspected by a microscope. And altered if necessary. This is slow and stops any ongoing computations (it will also freeze the timers and the oscillators, if possible) but the CPU won't notice that (comparably very much) time has passed. Of course any realtime events such as RF transmissions cannot be stopped.

    In addition, the PC communicates with an MSP inside the FET. And this MSP does the actual JTAG access by toggling its port pins by software. And does the USB communication to the PC on the other side.

    Doing a serial communication through JTAG is the very last way to communicate with the target MSP and has only one single advantage: it does not need additional lines beyond the existing JTAG connection.

    Steve Kranish said:
    WHY does plugging in the USB connection from the ez430-RF2500 cause my computer to virtually stop

    Nobody ever said that USB is fast, easy to program and reliable. And it took many years of work by many companies, hardware and software, before it was almost easily usable on the host side. Still any device can bring the PC to a sudden halt when plugging it into an USB port. Not only your board, also any USB stick, an USB harddrive or DVD drive. If you insert a bad DVD, it can stop your system for minutes. A faulty USB controller in an USB device can even make the whole system crash. I once had such a thing. Put it in any windows PC and it crashed. Two others of the same brand are working fine.

    Steve Kranish said:
    WHY do you use a java implementation that constantly pings the internet, and hangs the system while waiting for it to time out?

    Ask those who did the Java implementation.

    Steve Kranish said:
    WHY can't I find any meaningful help on the EXACT phrases found in the CCS menus?

    If you don't know why you can't, who else should know?

    Steve Kranish said:
    WHY is CCS non-deterministic?

    Is it? Or is it the user who's not deterministic? Well, the user always is, by definition.

    Steve Kranish said:
    WHY, if this is based on open source software, CANNOT TI fix the stupid 'phase error' warnings about files being 2 seconds out of date?

    How can files be 2 sec out of date? Ask your local OS. It's correct behaviour of an IDE warning about clock skew. It's not correct that files are written in the future. Most likely those who have thios problem have a fast system clock (where a second is shorter than it should be) and are updating their time with an NTP client. Which pushes the clock back and any just written files into the future. I wonder how you'd complain if the IDE would NOT warn and simply act as if the file time were correct. With really undesireable results.

    Steve Kranish said:
    WHY is CCS SOOOOOOOOOOOOO SLOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOW?

    If it's such a pain for you, why do you still use it? There are other compilers available.
    And sometimes, defragmenting the HD helps too speeding things up.

    I'm not a TI employee, but if you got a feeling that I dislike what you write here (mostly how you write), then you got your first point.

  • Hi,

    There is always a risk of causing ire among the community by posting to a thread that is over four years old. Yet in this circumstance is seems appropriate as the problem is the same or worse and having the history intact seems valuable. Coupled with the fact that, apparently, TI has never really addressed the problems as previously documented, is both technically and commercially relevant. Also the EZ430-RF2500 is still an active TI product.

    I would like to specifically address the post of Jun 30, 2010 by Eric Loeffler.

    "The backchannel should only be used for application development."
    The current implementation is inadequate even for this purpose:
    1 - plugging in the "USB debugging interface" with an attached "target board" seldom results in a successful install of the usbser.sys (Microsoft) driver for the USB device.
    2 - re-plugging into a different PC USB port may or may not result in a successful driver install.
    3 - rebooting the PC always results in an unsuccessful driver install. It is so unreliable is to make code development almost impossible.

    "the eZ430 backchannel UART you are referring to is not supposed to be used in final products."
    While this is sort of a restatement of the User's Guide Notice, it is somewhat misleading. "This evaluation board/kit is intended for use for ENGINEERING DEVELOPMENT, DEMONSTRATION, or EVALUATION PURPOSES ONLY..." Given the attachment instability problems stated above, it isn't appropriate for development, demonstration or evaluation.

    I, like several who have posted on this problem, believe that the source is the firmware on the "USB debugging interface". Since TI does not share the firmware in the "USB debugging interface", it is impossible for TIs client to resolve this instability on their own but must rely on TIs sense of responsibility and good engineering practices to "step-up" and support its user community. I think this thread reflects an interest and desire on the users' part to be successful with the eZ430-RF2500 product. What we need is TI to join with us and fix the attachment problems once and for all.

    Sincerely, Jon

  • Hmm.. the project I was working on fell of a cliff. I guess some things just fix themselves.

    Lets see here:

    'a thread that is four years old'

    and

    'TI has never really addressed the problems as previously documented'

    I think the lack of any meaningful or helpful response from TI means.. they DO NOT CARE. We are, after all, just customers; why should they waste their time on us?

    I am wrapping up a project (that I did not start) that will consume 500K to 1M SOCs a year to start. I never bothered to contact TI with questions, and I never bothered to post here. I just could not imagine their finding 5 minutes for a customer who is only spending a few million dollars. There are always bigger ships to sink.

    If I get to do a redesign, I will push hard for a move to another vendor.

    Steve

  • In the last years, TI has updated their drivers many times, and so did they update firmware of the EZ tools. The RF2500 dongle uses more or less the same EZ hardware as the LaunchPad and most users of these never had any problems. However, you cannot expect that your 4 years old hardware magically changes its layout to more recent revisions or that the firmware magically changes to a newer one. My 10 year old car also didn't turn into the latest revision just because the manufacturer released a new one with some improvements.

    Even in the past, most people never had problems. But since people insist in using a PC, an individual mixture of components and software, it is virtually impossible to create something more complex than an USB memory stick that will work on really all PCs. Jsu tlike there is no one-size-fits-all shoe for all humans despite of their individual gene mixture.

    It also didn't help that Microsoft constantly changes their driver models, so things that used a workaround here to implement things that weren't thought of when designing the OS, suddenly stop working. I'm pretty sure with a PC like the ones used in teh TI hardware labs you'll never encoutner a problem. But with all the othe rindividual components and drivers... Even the most popular and sure working medicines may stop functioning when used together with an (unrelated) other one. Software (including drivers) isn't different.

    You may try to download the latest drivers (uninstall the old ones first). Or using a different PC. Or check which other, often poorly designed 3rd party software conflicts with the EZ driver installation (e.g. a custom USB stack for the non-common USB controller, some smartphone syncing software that hijacks newly attached devices, whatever)

    If it were a general issue, there would be way more complaints in this forum than a thread that was sleeping for 2 years and then 2 years again.

  • Wrong-o, wrong-o.

    How much does TI pay you to write these blame-someone-else apologies? You seem to like writing them; just like a reply (gasp!) from TI, they provide absolutely no useful information.

    Lack of complaints does not mean lack of a problem; it means that most of us just put up with the lack of help from TI, and move on. I, for one, have largely abandoned TI as a vendor. I have written here as a response; I no longer waste my time asking TI for help with their bugware.

    Despite all your drivel about complex configurations, etc, let me say this again: I use FTDI USB to serial adapters ALL THE TIME and NEVER HAVE ANY PROBLEMS WITH THEM. FTDI seems to have figured out the magic formula for a STABLE USB DRIVER without attempting to blame Microsquish, Users, other applications, etc. IT JUST WORKS CORRECTLY, ALL THE TIME. I have not needed to download a new FTDI driver in years. Sadly, the same cannot be said of TI's driver arrangement, and I am not the only one to observe it.

    If this is somehow not a "general issue" it is perhaps because a lot of people do not know how to use a serial port at all.

  • Steve Kranish said:
    How much does TI pay you to write these blame-someone-else apologies?

    Nothing. However, sometimes someone else is blamed just because someone else is to blame. In way too many cases I have investigated regarding my companies products, the problem was found sitting on the chair before the computer.

    You can't say 'FTDI has produced a stable driver so TI should be able too". The basic TUSB driver is simple compared with the application UART driver required by the EZ430. The TUSB driver is stable too and offers the same funcitonality as the FTDI you used for comparison. However, this functionality won't by far be enough for doing the things the application UART driver has to do. It's like comparing the driver for a simple D/A converter (also called USB headphone) with the driver for an external MIDI mixer.

    besides this, that you have no problems with the FTDI driver doesn't mean nobody has. Just like I don't say that you can't have problems with the TI driver because it works flawlessly for me.

    Steve Kranish said:
    If this is somehow not a "general issue" it is perhaps because a lot of people do not know how to use a serial port at all.

    You'd be surprised how many people do not know how a serial port works and how to use it. Or what USB does to a serial connection (latency even for the control signals etc.)

    However there are exactly three possible explanations for the situation you face:

    1) out of millions of users there are only a very few who have problems so they don't justify the effort. Especially if the problems cannot be reproduced in the lab without having the PC of these users for investigation of the problem.
    2) there are only two or three users of this product so any further support doesn't justify the effort.
    3) there are millions of users with problems and all but two or three do not knowhow to post a quesiton in a forum.

    The third is rather unlikely. I've seen what happens in a support forum when a faulty product is released.
    The second is unlikely too, because then the product had vanished form the shop long ago.
    leaves the first situation.

    To ensure 100% compatibility, TI could sell the experimenters kit with a PC that has fixed components and a specific OS installation, where adding other components or installing other software is prohibited. This has happened before. The PC was called 'Macintosh' and the system was for use in the prinmting pland and graphical desing business. However, the prices had several digits more before the decimal point, compared to the EZ430-RF2500. I doubt such an "MSP development station" would sell, but it would definitely work as expected.

  •  Ref: onTue, Sep 11 2012 6:14 AM In the last years, TI has updated their...

    Forgetting the number of unfounded assertions you make without reference for a moment,

    I STARTED with installing the latest eZ430-RF2500 software from TI; slac139f. So I believe that I have the latest available software. In fact the driver installed for the "MSP 430 Application UART" com port is Microsoft's usbser.sys, v 6.1.7601.17514. If there is something more current that should be used, I would, of course, be interested.

    I believe that the problems exist in the firmware in the USB dongle. Either in the TUSB3410UF (26KB code space) or the M430F1612 (55KB code space). I am not aware of any updates from TI for the USB dongle firmware. I am also not aware of any public source-code for the firmware from TI. I am also interested in any updates or fixes available for this part.

    I am going to copy the last paragraph from my previous post, since I still think it summarizes what I am asking for:

    I, like several who have posted on this problem, believe that the source is the firmware on the "USB debugging interface". Since TI does not share the firmware in the "USB debugging interface", it is impossible for TIs client to resolve this instability on their own but must rely on TIs sense of responsibility and good engineering practices to "step-up" and support its user community. I think this thread reflects an interest and desire on the users' part to be successful with the eZ430-RF2500 product. What we need is TI to join with us and fix the attachment problems once and for all.

     

     

  • Jon Peterson said:
    In fact the driver installed for the "MSP 430 Application UART" com port is Microsoft's usbser.sys

    So why don't you blame Mcrosoft if the driver doesn't load?
    However, loading usbser.sys is just the end of much more that hapens under the hood before this driver is loaded. Or not.

    Jon Peterson said:
    I believe that the problems exist in the firmware in the USB dongle.

    Possible, but since the TUSB is untouched for anyone and only a few have problems, this is mroe than unlikely. Same for the 1612, as it has nothing to do with the USB stuff at all.

    Jon Peterson said:
    I am also not aware of any public source-code for the firmware from TI

    No, TI has never released any firmware sources for the 1612. Because it is much of the intellectual property that makes a FET (including the 'big' ones) doing its job. So releasing sourcecode would give the FET production away for nothing.

    Jon Peterson said:
    I am also interested in any updates or fixes available for this part.

    Those are part of each new version of the MSP430.dll that comes with the latest releases of CCS or IAR. MSP430.DLL updates firmware for TUSB and for the 1612 in all FETs - if necessary.

    So instead of ranting about TI's in ability to provide a driver that runs stable on your system (on mine, it does), what about starting to provide information that could track the issue down? Processor, board, chipset, USB controller and USB hubs, OS version, other installed software and USB drivers, other attached USB hardware etc. Sometimes the video driver interferes with USB data transfers because of incompatibilities in the interrupt chain, sometimes a different USB port or a different loading order of the USB drivers makes a significant difference etc. etc. etc.

    As I stated before, to fix a problem that affects only a few of many customers, one would need his PC to track the issue down.

    I understand your frustration. It's not fun having a problem and no solution.
    However, in near future, your current PC will be obsolete anyway (as it will always be, if it isn't already, due to planned obsolescence) and with the new one, maybe it works like a charm from the first moment. :)

  • Dear Mr Apologist:

    Allow me to repeat myself:

    Despite all your drivel about complex configurations, etc, let me say this again: I use FTDI USB to serial adapters ALL THE TIME and NEVER HAVE ANY PROBLEMS WITH THEM. FTDI seems to have figured out the magic formula for a STABLE USB DRIVER without attempting to blame Microsquish, Users, other applications, etc. IT JUST WORKS CORRECTLY, ALL THE TIME. I have not needed to download a new FTDI driver in years.

    I have 5 (count 'em, FIVE) computers on my desk right now. At one time or another, all of them use something with an FTDI USB to serial chip attached to them. All are at least slightly different. I do not remember the last time I had to download and install an FTDI update. THEY ALWAYS WORK. They have been used in tens of millions of products, and most users are probably unaware of their presence.

    If the functionality of the serial channel on the RF2500 board was too complex for TI to do it correctly, they should have had someone else do it.This is not rocket science.

    Again, lack of complaints does NOT mean a lack of problems, only a lack of complaints. There seem to be plenty on this thread. It went silent for a long time because we all accepted the same thing: TI is incapable of fixing the problem. Why should they? This are cheap kits, and many wind up in the hands of students who barely understand them - and are highly unlikely to do something as complex as use the much ballyhooed 'backchannel UART' for anything.

  • Jens-Michael Gross said:
    So instead of ranting about TI's in ability to provide a driver that runs stable on your system (on mine, it does), what about starting to provide information that could track the issue down? Processor, board, chipset, USB controller and USB hubs, OS version, other installed software and USB drivers, other attached USB hardware etc. Sometimes the video driver interferes with USB data transfers because of incompatibilities in the interrupt chain, sometimes a different USB port or a different loading order of the USB drivers makes a significant difference etc. etc. etc.

    I have not been, nor do I "rant". Your personal attacks are not helpful, professional nor wanted. So far you have written more than anyone else without providing any useful information. I would personally request that you think twice about posting until and unless you have useful information to provide.

    I will be happy to provide, to Texas Instruments, any and all such information that would prove helpful in finding the cause of the problems we have been seeing. I don't go on fishing expeditions however. I have been on too many of them: tell me this, tell me that, try this, try that...without any real focus or internal knowledge.

    I find it interesting that in all of this discussion we have NOT heard from anyone that works at TI.

  • Jon Peterson said:
    I have not been, nor do I "rant".

    Sorry, my fault. I didn't notice that there are two people answering and confused you and Steve Kranish. Who had and still does. I hereby officially redirect the last part of my last post to him. (and if you read his previous posts, you'll see that is was not an attack of mine but rather a defense)

    Jon Peterson said:
    I would personally request that you think twice about posting until and unless you have useful information to provide

    Well, what's useful or not highly depends on the point of view. Often enough one believes that only an information that provides an instant solution is to be considered 'useful' while others consider something useful that changes their path of thinking into a direction that leads them to their own solution.

    Since there is apparently no 'well, we know your problem and you only have to press this button and all will be fine' type of solution, providing an approach to find the cause of failure in your specific situation (that cannot be easily reproduced by anyone else) could be considered useful - if you're willing to use it for own work. Of course you always have the option to ignore it and wait for an out-of-the-box solution that (also apparently) didn't come for years. Your choice. I can't give you what I (and apparently nobody else) have.

    Jon Peterson said:
    I don't go on fishing expeditions however.

    Unfortunately, if it comes to (WIndows) PC issues, this is somethimes the only thing you can do. If everything on a device were from one and only one manufacturer, I'd expect everything to work when the product is released. But since a PC is a mixture of hundreds of components of hundreds of manufacturers, each one is more or less a unique device and problems may arise on one system that are absolutely not reproducable on another.

    For example: in the (very common) case of CSS not being able to find the FET, it turned out that in one case it was the Razor mouse driver, in another case it was a smartphone synchronizing app that was grabbing the connection as soon as it appeared in the device manager. Nothing TI could have done would have prevented this. And since nobody at TI was using a gamers mouse of this brand or this smartphone on one of the development machines, no effort in the labs could have led to a solution. However, the (not useful, in your eyes) information of possibly conflicting software allowed the two people to detect what's going on on theit specific system and solve the problem permanently.

    Jon Peterson said:
    I find it interesting that in all of this discussion we have NOT heard from anyone that works at TI

    Interesting, maybe. But what conclusion do you come to by this piece of information? negatively biased people could interpret it as 'they fear to show their incompetence', but a neutral view could come to the explanation that there is no reason to answer because everything that could be said has already been said. many other interpretations are possible too.

  • Steve Kranish said:
    I use FTDI USB to serial adapters ALL THE TIME

    You see but you don't read - and obviously don't understand. Providing a simple serial-over-USB bridge is primitive first-year-USB-engineers stuff. If it wouldn't work, Id consider the people involved in it as highly incompetent.
    The EZ430 driver constellation is far more complex to provide both, a serial port and a debug connection at the same time over the same device. And is something that the windows driver system wasn't really designed for. So stop comparing apples and pears and blaming the pears for not being round enough.

    Steve Kranish said:
    If the functionality of the serial channel on the RF2500 board was too complex for TI to do it correctly

    There is no 'the serial channel', but something way more complex. That's what I was trying to tell you all the time.

    Steve Kranish said:
    This is not rocket science.

    Why does everyone think that rocket science is all that complex? It's way more difficult to make a complex construct like a windows PC do something you want (unless you want something that was already planned to be supported) than shooting a rocket into the sky. The rocket is jsu tmore expensive and if it explodes, you cannot just format the hard drive and re-install.

    Steve Kranish said:
    Again, lack of complaints does NOT mean a lack of problems, only a lack of complaints.

    Yes. But lack of success stories doesn't mean there are none. Nobody comes to a support forum to tell 'I don't need support because it works fine'. And I want to believe that people who are trying to develop micrtocontroller applciaitons are smart enough to find a support forume if they have problems. Yet there aren't many complaints. So either there is nobody else having problems or all these people who encountered problems solved them by themselves.

    I don't deny the problem, I only deny the global significance of a few occurrences.

    Steve Kranish said:
    TI is incapable of fixing the problem.

    Agreed. But this doesn' tmean it is lack of competence. More likely is lack of reproducability.

    Steve Kranish said:
    This are cheap kits, and many wind up in the hands of students who barely understand them - and are highly unlikely to do something as complex as use the much ballyhooed 'backchannel UART' for anything.

    But those students are usually really great in finding a support forum and calling for help. There are several "I have this or that to do, so please give me a ready code solution" (with ot without a 'please') every week. And also lots of 'FET not found' problems too. So why are there almopst no calls for help regarding the RF2500 installation? If you search for this term you'll find that there are many threads regarding it, but almost all are related to help with the code, not with the installation.

**Attention** This is a public forum