LPC1768 USB hangup

The problem is that a USB serial device can be closed by disconnecting the device, whereas a real serial port cannot. The comms program has to be aware of USB serial ports. HyperTerm is just too old.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

I'm a big fan of Putty for this sort of job.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510
845-480-2058

hobbs at electrooptical dot net
http://electrooptical.net

My PowerBasic program did the same thing. What do you mean by "be aware" ? What would a program do the prevent the hangup? Closing the open port after the disconnect is apparently too late.

Putty has the same issue. It's a window problem.

There is NO program on ANY operating system that can survive a USB serial port disconnect.

I have tried many, wrote some of my own.

Windoze, Linux, CE, none can survive without a program restart.

hamilton

This is an annoying and complex problem that, as far as I know, does not yet have a good solution from the operating system standpoint. I am not totally sure what the root of the problem is but it could very well be related to the type of combo drivers that are used to support USB/COMM port type devices.

At the company where I work we had the very same problem as you have described with a USB port connected into an external box where the USB terminated into a 1->4 USB hub and then into an FT232R chip that then went TTL serial port to a SiLabs MCU. The fix that was used was to compose the host side program as multiple threads where the thread that managed the "virtual serial COM port out USB" could be unloaded and restarted from another monitoring thread. The monitoring thread kept an ongoing heartbeat packet sent to the external device whenever there was no normal serial traffic going on. If the serial traffic, either normal or the heartbeat type, ever encountered an error due to sudden removal of the USB cable the monitoring thread would unload the thread that owned the crashed virtual comm port. It would then use some API calls that are available to automate the same things you do in device manager to to disable/enable the port. Then finally it could reload the thread that managed the Comm port whilst it waited for the device to reappear as connected.

Needless to say this was a complex solution to make the usage model of the software a whole lot more user friendly. Without that the use of USB Serial devices basically sucks if you suddenly unplug the USB cable whilst it is in use.

Michael Karas

--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com

Going into Device Manager and disabling/enabling the port fixes the hangup. Maybe there is a command-line equivalent. If so, I could shell out to that.

This maybe?

Writing your own serial emulator talking to the device driver meant for a USB serial chip can help SOMETIMES.

Otherwise checking handles, and device drivers before nearly every call or putting timeouts on serial port transactions can help. Make sure you have a tiemout handler to close and open device.

Timeouts have existed on most serial ports and printer ports on most operating systems for a long time. How well they work depends on the operating system and its drivers as well as the USB driver.

Some drivers have a call to cycle the device from the driver, which might help depending on how well written the driver is.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

"John Larkin" wrote in message news: snipped-for-privacy@4ax.com...

I have a similar problem with a Microchip USB stack. It's not serial emulation. If the device is unplugged the calls on the host may hang, and the whole host controller is hung. Windows will not shutdown, and is stuck on the USB hung call. The multithreaded routine that Mike explains seem to be the only solution. You could do a 'try' 'catch', but if there is no exception thrown then it's useless.

Cheers

OK, I just tried this, did not work.

Win7-32bit, Teraterm 3.13

I unpluged a Prolific USB-to-Serial Comm Port device Re-plugged USB device Teraterm does not work.

On the Prolific I have a PIC board that I reset to see Copyright message.

But, this did work:

In Teraterm, Setup-> Serial port select other serial port, got a Tera Term: Error Cannot open COM2 [OK]

Setup-> Serial port select original serial port (no error) Serial port works.

I will look into this.

Thanks

I figured out how to detect the unplug of PL2303 serial ports, (I think by looking at the errors returned when reading the port) but yeah my program just closes the port, exits and gets restarted. I haven't tried to wait and reopen the port

--
?? 100% natural

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net

I have a product with the LPC2368 that uses USB CDC Virtual comm that works OK but see the same exact issues. We also use the LPC1768. Very similar these 2 processors in their peripherals AFAIK.

I am amazed that I got it to work in the first place, and then the .inf file to use with Win 7 when that had to be done.

I have tried and tried to find out how windows can tell things about this USB connection to say, find out automatically what comm port it is on without having to manually go to device manager etc, but I think that anybody that ever knew anything about this stuff is either dead or retired. Can't find anybody that knows anything about USB driver internals, etc or its interaction with the OS.

I just wish I could do a reset of windows USB software or something like that when USB goes to hell.

boB

The point is detecting the hangup.

When you disconnect the USB/serial dongle, the ReadFile system call returns with "ok, 0 bytes read". The correct reaction is to stop the program at this point, close the serial port, and offer the user a "reconnect" button.

With a real serial port, you can assume that if it returns "ok", it also returns ">= 1 byte read", and you can call ReadFile again to wait for the next bytes. Programs not aware of USB/serial ports will thus call ReadFile again, receive the same reply again, and enter an infinite loop.

Stefan

Not true. For starters I use the wxSerial cross platform serial port control stack under Windows. Secondly you should make sure the USB device is disconnected for at least 5 seconds. This makes windows take the com port down so the program gets a proper error. In my USB gadgets I start the USB stack after 5 seconds. Oh and I just re-tested with Hyperterminal. Ofcourse you need to re-open the port.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

It's been a while since I rewrote our terminal emulator for USB. I think that we check the error code returned by ClearCommError(), and check for CE_MODE. If this is set, the channel has been disconnected and you should close the comms.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

Would you like me to demonstrate?

Stephen

-- Stephen Pelc, snipped-for-privacy@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: - free VFX Forth downloads

Sharing you code would be helpful.

hamilton

The important bits for Windows with VC6:

// ================================================================= // Serial line routines - these simulate the Forth KEY KEY? and EMIT // No attempt at efficiency is made - the PC always gets faster, and // we can improve these at a later date. // =================================================================

int TargetError=0; // set when target reports error

// return number of characters in serial input queue DWORD SerKeyQ( void ) { DWORD ErrorCode; COMSTAT cstat;

if (ThrowReason != 0) { ErrorCode=ThrowReason; ThrowReason = 0; throw( ErrorCode ); } if (bClosing) return 0; if (hCom == INVALID_HANDLE_VALUE) return 0; if (hCom == NULL) return 0; if (!bConnected) return 0;

ClearCommError( hCom, &ErrorCode, &cstat ); if( ErrorCode & CE_MODE ) // check for close; SFP009 { hCom=NULL; bConnected=FALSE; WriteStatus( "Comms closed", 1 ); return 0; } return (cstat.cbInQue); }

// return next character in serial input queue char SerKey( void ) { DWORD bytesdone; char Buffer[4];

while ( SerKeyQ()==0 ) { if (hCom == INVALID_HANDLE_VALUE) return 0x0D; if (hCom == NULL) return 0x0D; if (!bConnected) return 0x0D; // Sleep(10); Sleep(5); if (bClosing) return 0x0D; } ReadFile( hCom, Buffer, 1, &bytesdone, NULL ); return (Buffer[0]); }

Showing you the whole lot will show you how to write a mixed Forth and C application which is now being converted to pure Forth because debugging this sort of stuff is so much easier in Forth than in C.

Stephen

--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

I can close the port manually, and re-open it, or kill the program and restart it, but the thing is still hung. I have to use Device Manager to disable/reenable the comm port before it will work again.