Intermittent connection failure when using USB-Serial adapter

[sfrank]

For our microprocessors training lab, we're using Wytec's Dragon12-Plus training board with the Freescale Serial Monitor installed. This allows us to connect to the board via CodeWarrior (Special Edition). Since we have USB-only computers in our labs, we are using some generic USB-Serial adapters (supplied by our IT department; not our choice). From the device naming and drive software, the adapters appear to be based on Prolific's chips, which seem to be just your basic, run-of-the-mill USB-Serial adapter chips. We assign COM4 to the USB-Serial converter, and then point Codewarrior to COM4 when it goes to download to the board.

Everything works fine... most of the time. However, once in a while Codewarrior will stop recognizing the COM port. It will see the COM port, as in "COM4" appears in the menu as an option, but then it will fail to communicate with the port and give a "could not communicate with the hardware" type error. This will typically happen in the middle of working on a project after the connection has been brought up and down a few times, such as when a student loads successive versions of code into the board to test.

Once communication fails, it seems a bit arbitrary how to restore it. We've tried the following, all of which seem to work part of the time but not all the time:

• Closing, then reopening, Codewarrior
• Closing codewarrior, logging out, logging back in, then reopening Codewarrior
• Disabling then re-enabling the COM port device in Device Manager (w/out reboot)
• Rebooting
• Disabling then re-enabling the COM port device in Device Manager (w/ reboot)

The items towards the bottom of the list seem to work more consistently, but on one occasion I tried all five of those things with a student and wasn't able to restore connectivity. I had him switch workstations. A different student came along later and used the first workstation without any problems.

I also check the target board settings every time this happens, including making sure jumpers and DIP switches are in the proper locations. They nearly always are (usually because it was working and then stopped working, so the student already has them set correctly).

Also, in case someone asks, I'm pretty sure it's not the USB-Serial hardware (or at least not only the hardware). Before upgrading our boards, we used to use the old Buffalo monitor with HC11-based boards, accessed through THRSim11, and we never had any problems of this sort. Something in the particular interaction between Codewarrior and the hardware is causing the problem.

I've seen a lot of posts around here about Codewarrior simply not recognizing COM ports (ie, they don't show up) and how to fix that, but very little about intermittent communication failures of the type I'm experiencing. It's very strange, precisely because it works perfectly and then just stops. Does anyone know what might be happening, and/or how to make it stop happening?

[J2MEJediMaster]

Maybe you forgot to mention it, but did you try cycling the power on the training board, or the USB to serial adaptor? I'm thinking that either the board or the adaptor missed a handshake or a command exchange, and it sits in a particular mode, waiting for a command. Meanwhile the system thinks it sent a command and starts waiting for a response... Deadlock. OK, you will lose the current session, but that might get you back to debugging faster than trying lot of things on the workstation end. Some of the more extreme examples you mentioned to cleasr the problem are going to trash the debugging session anyway.

---Tom

[sfrank]

Power cycling the board was one of the things we tried, yes. I did forget to put it in my list, but that's because it didn't work when we tried it. (Resetting the board didn't work either.)

We did not try power cycling the USB-Serial converter via physically unplugging it, although we could try that. The problem is that the computer is tucked away under a counter and the back is hard to reach, so power cycling the converter would not be a very convenient solution.

Part of the testing problem is that I have a hard time duplicating the bug. Whenever I want to make it happen so that I can test how to fix it, it doesn't show up. Very strange.

[J2MEJediMaster]

You might try the following, in order of cost and pain:

1) See if you have an older version fo CodeWarrior. (Help > About Freescale CodeWarrior > Installed Products.) Perhaps downloading and installing a later version of the Special Edition of CodeWarrior will correct the problem.

2) Buy a serial card and try that. There's no guarantee that it will solve the problem, but anything to simplify the debugger's chain of communications might help.

---Tom

[sfrank]

Hmm. Thanks for the advice. (1) may be an option, as it looks like version 5.0 just came out. We're using 4.7, which we downloaded and installed this past January. Unfortunately, it's likely we won't be able to do this lab-wide until semester end, so I won't know for a while if this is a potential fix.