PropPlug reset on USB activity

TreeLab

I have a SpinStudio board that is wired to the PC via the PropPlug. WHen I connect a USB drive (either a flash or a portable HDD) to another port the program running on the Prop seems to reset. I do not think it is a power issue since the PropPlug is working on a powered USB hub. THis machine is running XP Service Pack 2.

Is this a known behaviour, or is my hardware getting flakey (not the SpinStudio Brian : It is terrific!). Any suggestions for a fix?

Cheers!
Paul Rowntree

Bobb Fwed

I have had the same issue with my custom boards. I've found if I wire the ground of the PropPlug to the device before I hook up the other wires, it doesn't reset the device.

Mike Green

TreeLab,
I think that sometimes, when you plug in a device that draws some power, there's surge that causes the USB hub to reset which causes the PC to have to go out and catalog what devices are still out there. That enumeration process resets the PropPlug (and other USB to serial adapters) and causes the brief loss of DTR (data terminal ready) which resets the Propeller (or Stamp).

Bobb Fwed,
You're not really supposed to connect a PropPlug or other external device to a "live" custom board unless you've designed for that circumstance. I would expect the Propeller to reset if you connect the PropPlug without the ground connecting first. That's why connectors designed for "live" insertion are designed so the grounds have to touch first.

Bobb Fwed

Right. And by "designed for that circumstance" you mean what you said in your last sentence?
It's not normally critical that my devices don't reset when I plug them in, but sometimes it is useful. I have a bit of a mickey mouse setup to hook my boards to the PorpPlug; I just use the three-wire servo cable to use for data and reset, and a separate wire for the ground. This allows me to attach the ground first (and separate) before the other connectors.
When you say, "You're not really supposed to connect a PropPlug or other external device to a 'live' custom board", it's not going to damage the plug is it?

TreeLab

Thanks Mike;
I had not realized that devices could glitch the system even on other powered hubs, but your explanation makes sense.

To take this one step further, I had been planning to use Hanno's ViewPort (what a great program!) as the permanent front-end to my device, but that means keeping the high-speed PropPlug in place, and therefore being subject to these 'glitches' when another device is connected. Is there any way around this, short of putting a removable jumper on the DTR line for use during programming?

Cheers!
Paul Rowntree

grasshopper

I think that the driver for the flash device or any other is causing the propeller to reset. If a program seeks a port on start up it will write to each port and that often resets the propeller becaue it is thinks its getting new code.

I solved this problem by using a jumper in between the reset line and the FTDI IC.

Capn_Dave

When the USB port is connected a reset is generated. When the serial port connected is opened/closed DTR generates a reset.
My solution is to cut the track from the FTDI reset pin to the Propeller and install two jumper posts. Connect a removable jumper to the posts to program and then remove for runtime.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Caught in the PropWash

TreeLab

So this begs the question : if some device is transmitting over the bus when another is connected, does the bus get reset, and if so, how does the system re-synch?

Cheers!
Paul Rowntree

mlerley

I think I found the (a?) solution to this issue! From the FTDI Advanced Driver Options Application Note AN_107:

6.6.7 Disable Modem Ctrl At Startup
This option is used to control the modem control signals DTR and RTS at startup. In normal
operation, the modem control signals at startup follow the behaviour of the legacy port. However,
due to timing differences between a legacy COM port and a virtual COM port, a "spike" on one of
these signals in the legacy port can appear as an assertion of the signal in the virtual COM port.
Devices that monitor these signals can enter the wrong state after an unplug-replug cycle on USB.
Note that if the "Serial Enumerator" option in the property page is selected, then the enumeration
sequence causes the modem control signals to change at startup. So if it is necessary to select
"Disable Modem Ctrl At Startup", then it is likely that "Serial Enumerator" should be unchecked in
the property page.

Indeed, I changed the advanced port settings in Device Manager for the serial port in question - I disabled "Serial Enumerator" and enabled "Disable Modem Ctrl At Startup" and now plugging or unplugging another USB device from the PC, even a port on the same hub, no longer causes the propeller to reset! Not sure if those settings can be made programatically at runtime yet but I feel like this is some progress. Hope this helps somebody.

tonyp12

Someone modified the driver on Windows 10 for a CP2102 that also have this problem:
https://www.silabs.com/community/interface/knowledge-base.entry.html/2011/09/19/undesired_dtr_toggli-WOGD

The DTR pin toggling is due to a feature called 'serial enumeration' in Windows.
Whenever Windows discovers a COM port, it automatically opens the port and toggles the signals as part of a process to check if the COM port is connected to a serial mouse.
This is a legacy feature to support older serial mouse devices.