Cable Disconnect bug, PIC18, USB/RS232 Emulator

[pratiken]

Hi guys

I have a device that uses a PIC18F2550.
I have firmware for it that emulates RS232 over USB.
The issue is when I disconnect the device WHILE connected to the COM port via Putty or hyperterminal.

Basically, when I disconnect the cable, Putty no longer responds (as expected). But when I plug it back in (without closing Putty), Putty continues to be frozen. As it is a COM port, why does it not pick up where it left off and continue function after plugging the device back in?

Instead, I have to completely close Putty/hyperterminal, disconnect the device again, reconnect the device, and then open a new instance of Putty in order to get it working again.

I'm really not sure where to begin looking for a solution to this issue...

Thanks for your help
Pratiken

 

[horace1]

I have the same effect with FTDI USB TTL cables and Teraterm

When the USB TTL cable is connected a virtual COM port is created and Teraterm can connect to it as though it is a real hardware port such as COM1:.
When the USB TTL cable is disconnected the virtual COM port disappears (you can see this in the Control Panel > System > Device Manager) and Teraterm looses communication
When reconnected the virtual COM port is recreated but Teraterm (and I guess PUtty) does not have the capability to reconnect - it has to be shut down and restarted

when writing PC software (in C++, C#, VB, etc) to communicate with our own USB devices I always include functionality to recover from disconnection - you can always write your own terminal emulator to do this with your PIC18 board - I would assume that C++ would throw an exception when the virtual COM port was lost and one could wait for reconnection to reopen the port and restart communication

 

[pratiken]

So the problem lies in the PC software (teraterm, putty, hyperterminal, etc) and not the firmware on the device?


Bummer

 

[horace1]

So the problem lies in the PC software (teraterm, putty, hyperterminal, etc) and not the firmware on the device?


Bummer

I guess they were all implemented in the days of hardware COM ports that did not go away
never been extended to handle port disconnect and reconnect