Objective Development Forums

I'm using PowerSwitch (ver. 2007-06-25) on a PCB. It's powered from the USB bus, and switches only two 5V relays, and a lot of optocouplers.
The problem is, that if (relatively small) eletrical EMI occours, (example a soldering iron plugged in nearby) the PowerSwitch disconnects.
Under Linux, it's comes back immediately with no problem. The only sign of the disconnect is in the dmesg log:
usb.c: USB disconnect on device 01:03.0-2.1.2 address 53
hub.c: new USB device 01:03.0-2.1.2, assigned address 54

But in Windows XP, it's gets lost forever, unless somebody phisically pulls out the USB connector and/or restarts the computer.
I'm not an expert in electronics, and I don't know how to handle this EMI problem correctly.
The disconnect occours the PowerSwitch's idle state, not when on of the relay switches.
I'm using shielded USB cables as long as possible, and using metal housing, but looks like it's not enough.

I have the same problems with USBasp programmer (on WinXP). Voltage surges from target (especially on power-up) makes device lost - only reconnection helps. Good, shielded cable helps a lot, but not totally.
PS: I have tested avr910 programmer with ft232 mc with the same cables and target - all works fine.

Yes, I have seen these EMI problems, too. I don't know what causes them, but I know that the processor goes through a RESET. I suspect that the spikes somehow couple to the RESET pin since any connection to this pin makes the problem worse. As far as I remember, I could prove that it's not a watchdog reset, but an external reset from the RESET pin.

I don't know how to fix the cause, but you can fight the symptom. At the beginning of main, both USB pins are set to 0, then a delay loop is started and then they are configured as inputs. Increase the delay to ~ 500 ms. This ensures that the host sees the reset and re-enumerates the device.

In my case it was not RESET. Firstly i have modified USBasp SW & HW - move D- pull-up to IO pin and watch this pin with oscilloscope - where was no impulses there. Then i have build optically isolated version (with 6N137) - disconnections occurs more rarely, but they not totally gone!
In second case USB2.0 cable with good shielding almost solve this problem. The device, that i tried to program, was a self-made frequency meter on mega8 with the following power supply: 220V -> Power switch -> 13V transformator -> Diode bridge -> 7809 -> 7805.
Can it be problems with LibUSB driver? Can HID driver usage solve this problem? Now i will build simplified version of AVR-Doper (ISP only, without HC126: can't buy it, substitute it with 4 NPN transistors) and test this in HID mode...

I doubt that this is a problem with the host side driver. Switching to HID won't help.

The original firmware was without the USB reset code. Inserting the reset code fixed the problem for Linux (Linux detects the disconnect condition fast enough). I think that's proof enough that the processor restarted execution at main().

If you use a scope to check for USB disconnect, please make sure that the initial disconnect code works and that the scope detects the spike reliably.

Could it be a brown-out reset steming from a glitch on the power supply?

It was definitely not a brown-out in my circuit because I used an AT90S2313 which has no brown-out detection. And I added all types of capacitors to the supply voltage in the hope that it would improve things.

christian wrote:I doubt that this is a problem with the host side driver. Switching to HID won't help.

Yes, i have tested it - no difference
But, i think, it is not a controller reset. When D- pull-up is controlled by IO pin, during reset this pull-up is disabled - device disconnects and window plays 'ding' sound... device leds blinks... And so why good shielded cable helps? But, i think, the only way to find what is happening, is to create a prototype board with e.g. mega16 and check it with JTAG.
I use a simple solution for USBasp programmer: move pull-up to IO pin and add a programmer reset button.

How long is the disconnect during reset? Windows detects it only (reliably) if it's at least ~ 500 ms long. Otherwise it may be "overlooked" and the device and host are out of sync with respect to the device ID.

You can only rely on the "ding" sound on Windows if your disconnect pulse is at least 500 ms long.

Good shielded cables can help because they add capacity from D+ and D- to ground. The data lines therefore catch less capacitive EMI.

If you find out how to suppress this type of EMI problem, please let us all know!