Cable Disconnect bug, PIC18, USB/RS232 Emulator

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

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

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


Bummer

pratiken said:

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


Bummer

Click to expand...

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