On 2012-07-08, hamilton <hamilton@nothere.com> wrote:> 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.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 ---
LPC1768 USB hangup
Started by ●July 7, 2012
Reply by ●July 8, 20122012-07-08
Reply by ●July 8, 20122012-07-08
On Sat, 7 Jul 2012 22:58:49 -0400, "Martin Riddle" <martin_rid@verizon.net> wrote:> >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in >message news:ha2hv75jdv48e93fib3jdv11lof2dup08k@4ax.com... >> >> >> We built a little picosecond pulse generator box with a USB interface. >> The USB is directly into an LPC1768 NXP ARM chip, and we're using the >> USB stack and inf file that Code Red provided. It enumerates as a >> serial port. It's "unsupported", which means it's *really* >> unsupported. >> >> Under Windows XP, there's a small glitch. I can plug/unplug the USB >> cable, and it always makes all the proper bleep/bloop >> connect/disconnect noises. It shows up as COM6 or some such. I can >> talk to it from Hyperterminal or from a PowerBasic program. But if I >> disconnect the USB cable while the port is open, it hangs up. The fix >> is to close the program, then go to Device Manager, disable it, and >> re-enable it. >> >> I've seen other USB devices behave this way, too. >> >> Anybody know what's going on, and maybe how to fix it? >> >> >> > >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 > >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
Reply by ●July 8, 20122012-07-08
hamilton <hamilton@nothere.com> wrote:>On 7/7/2012 5:00 PM, John Larkin wrote: >> On Sat, 07 Jul 2012 22:38:23 GMT, stephenXXX@mpeforth.com (Stephen >> Pelc) wrote: >> >>> On Sat, 07 Jul 2012 12:19:04 -0700, John Larkin >>> <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >>> >>>> Under Windows XP, there's a small glitch. I can plug/unplug the USB >>>> cable, and it always makes all the proper bleep/bloop >>>> connect/disconnect noises. It shows up as COM6 or some such. I can >>>> talk to it from Hyperterminal or from a PowerBasic program. But if I >>>> disconnect the USB cable while the port is open, it hangs up. The fix >>>> is to close the program, then go to Device Manager, disable it, and >>>> re-enable it. >>> >>> 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 >> >> 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. >> >> > >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.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=.) --------------------------------------------------------------
Reply by ●July 8, 20122012-07-08
On Sat, 07 Jul 2012 16:00:36 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:>>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 > >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.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
Reply by ●July 8, 20122012-07-08
On Sat, 07 Jul 2012 19:03:57 -0600, hamilton <hamilton@nothere.com> wrote:>Windoze, Linux, CE, none can survive without a program restart.Would you like me to demonstrate? 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
Reply by ●July 8, 20122012-07-08
On 7/8/2012 5:31 AM, Stephen Pelc wrote:> On Sat, 07 Jul 2012 19:03:57 -0600, hamilton <hamilton@nothere.com> > wrote: > >> Windoze, Linux, CE, none can survive without a program restart. > > Would you like me to demonstrate? > > Stephen >Sharing you code would be helpful. hamilton
Reply by ●July 8, 20122012-07-08
On Sun, 08 Jul 2012 06:26:49 -0600, hamilton <hamilton@nothere.com> wrote:>> Would you like me to demonstrate? >> >> Stephen >> >Sharing you code would be helpful.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
Reply by ●July 8, 20122012-07-08
On Sun, 08 Jul 2012 11:30:50 GMT, stephenXXX@mpeforth.com (Stephen Pelc) wrote:>On Sat, 07 Jul 2012 16:00:36 -0700, John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >>>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 >> >>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. > >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. > >StephenI 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.
Reply by ●July 8, 20122012-07-08
On Sun, 08 Jul 2012 09:07:45 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:>On Sun, 08 Jul 2012 11:30:50 GMT, stephenXXX@mpeforth.com (Stephen >Pelc) wrote: > >>On Sat, 07 Jul 2012 16:00:36 -0700, John Larkin >><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >> >>>>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 >>> >>>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. >> >>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 > >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.I had that problem with a Delorme BlueTooth GPS thingy. I ended up throwing it away because it wasn't usable.
Reply by ●July 9, 20122012-07-09
On Sun, 08 Jul 2012 11:31:34 GMT, stephenXXX@mpeforth.com (Stephen Pelc) wrote:>On Sat, 07 Jul 2012 19:03:57 -0600, hamilton <hamilton@nothere.com> >wrote: > >>Windoze, Linux, CE, none can survive without a program restart. > >Would you like me to demonstrate?Well, I may have to apologise! I have checked our code again on Win7-64 and XP SP3 with a Keyspan USA-19HS and a generic Prolific (branded Nikkai) USB serial port. Both PCs are fully updated. We're in the middle of an office refurb, so I have no easy access to other PCs or USB serial adapters. In both cases, neither PC generates any error bits in the variable specified by ClearCommError(). The controlling program still survives the experiences. The original code is marked as 2005 in the change markers and was throughly tested at the time. Oh, dear. There's a 1998 MSDN CD set somewhere ... I knew I shouldn't have thrown out the more recent ones ... 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
