Objective Development Forums

Hello!

If after some event PC loses USB-connection with device (with v-usb driver, of course) while physically it is still there, the connection can only be restored by either resetting the device or by unplugging it and then connecting to PC again. Somewhat similar problem is described in this thread, and an "event" was Windows sleep mode.

I'm building a PC-controlled power source, and the interface board is actually PowerSwitch with some extra functions. For me an "event" is manual switching power (220V AC) on or off. Board continues to function as intended except USB connection. Since connection loss happens even when there is _no_ galvanic coupling between interface board and _anything_ else except PC, I suppose it's because of EM interference from transformers.

test case:
220V AC <=> on/off switch <=> transformer
No other connections.
Tested hardware: my interface board, UsbAsp (both with Atmega8)
Firmware: PowerSwitch (both my modification and plain), UsbAsp, bootloadHID.
The difference from original is that I'm using Int1 instead of Int0 on both boards (was better for routing).
OS: windows XP with libusb-win32-0.1.12.1.
If I change switch state (in any direction), board in near loses connection to pc, but works fine otherwise.

Is there any way to fix it in firmware?
I would very much appreciate any help.

Sorry I cannot answer your question but I can confirm that this problem exists. My project is currently still on proto-board, one half of the board has my avr powered by usb, on the other side I have a simple oscillator powered by a stabalised 5v supply pulled from an old printer. Even when there is no physical connection between the circuits (not even ground), a simple matter of connecting the 5v supply occaisionally stalls the usb driver forcing me to reset. However since I decoupled my ADC pin with a small cap the problem occurs much less frequently, I was rather hoping it might just go away once I got everything soldered up on to a pcb.

I would also be very interested to know if there is a way to re-connect automatically through the firmware.

One possible thing to look at is the time during usb write to device read. If the avr takes too long to work with the device the usb may fall behind. Not sure about the details here but I have made this mistake before and the result as you described.

You can reconnect automatically if you connect the D- pull up resistor to an I/O pin instead of Vcc. See the USB_CFG_PULLUP_* macros in usbconfig.h . To reconnect, issue usbDeviceDisconnect(), wait 1-2s, then issue a usbDeviceConnect().

Grendel wrote:You can reconnect automatically if you connect the D- pull up resistor to an I/O pin instead of Vcc.

Do we really need extra IO pin to enforce re-enumeration like we do it just after usb initialization? Like this:
Unfortunately I have no spare IO pins this time.

And we should know first whether the connection is lost or not, shouldn't we? I don't think it is a good idea to reset usb every N cycles. But it's just a feeling, I don't know for sure. Maybe somebody here knows better?

Anyway I will try in the morning just to see if it works.

Edit:
Sorry, had no chance to try and will not have in the next two weeks

I don't know how clean is this workaround, but at least it works for me.
I just run this every 10s:

I can confirm that EMI (Electro Magnetic Interference) is a problem with AVRs. Switching an inductive load can cause the PC disconnect. Analysis has shown that the AVR itself performs kind of half of a reset. Some parts of the chip go into reset status, others don't. I have seen this even on projects without USB connectivity.

You can brute-force work around the problem by performing the USB disconnect when you suspect a problem.

Other than that, all measures which reduce EMI help. But this is a very complex topic.

Just an idea,

Periodically read a specific message from AVR-USB device. In switch : case of this message refresh a timer. If timer overflows reset the chip.If USB device
always works fine the timer should not have chance to overflow hence no reset occurs.

Reseting USB fixes connection problems but connect- disconnect sound in windows is an isue. My quesiton is: Is there a way to
disable this sound only for a given VID/PID USB device in Windows.

I am using win - usblib as USB driver. May be there is a way to fix this isue from driver.


Best regards
saltukasaltuka

I tried to use watchdog reset to init firmware when usb connection is broken. I will check the connection periodically from host software and clear a flag. If flag is not cleared IC will get into watchdog reset. This does not cause re-connect with usb hence no sound for disconnect - connect of usb device. Any idea about this solution is very appreciated.
Saltuka

Why should this prevent the disconnect/connect sound? A watchdog reset also triggers a disconnect. If it does not, there's a discrepancy in the host's notion of the USB ID and the device's notion.

You should be able to prevent EMI problems with a (very) good board layout.

christian wrote:Why should this prevent the disconnect/connect sound? A watchdog reset also triggers a disconnect. If it does not, there's a discrepancy in the host's notion of the USB ID and the device's notion.

You should be able to prevent EMI problems with a (very) good board layout.

Dear Christian, I am not expert on USB however the solution I adviced somehow worked for me. Could you explain little more what may cause "discrepancy in the host's notion of the USB ID and the device's notion." Actually after reset of device I can still read my usb parameters corretly and windows does not give plug - unplug sound.

If your main() routine begins with a usbDisconnect() which lasts for some time (all our examples do that), then I don't see a difference to initiating the disconnect somewhere during runtime.

If your main() does not do that, the host won't know that you had a reset. The USB driver's usbDeviceAddr variable is reset to 0, but the host tries to reach it under the address which was negotiated before the reset.

christian wrote:... Analysis has shown that the AVR itself performs kind of half of a reset. Some parts of the chip go into reset status, others don't. I have seen this even on projects without USB connectivity.

Sorry this is drifting slightly off-topic, but I was wondering if there were any resources to look into about this sort of "half-reset" problem? Thanks so much!

I have read about this when doing support. Somebody found out that the program was executing normally, but the I/O registers were reset to their RESET state. I have not verified this myself, so it may have been some other unexpected behavior.

On the other hand, I have seen lots of EMI problems with the AVR myself, especially with V-USB. Probably because a long cable is directly connected to I/O pins.