Yes, but there will always be a doubt regarding this theory until it is officially acknowledged by the manufacturer, which is doubtful...

There may be power supply issues like above if you connect devices requiring more power than the router can supply, but what we have here is definitely not power related.

So if you want to make sure your USB devices are working with an AR9331-based router, here is my advice: add an active (external power supply) high-speed hub

Some update...

Had no problems using MR3220 v2 as audio player/streamer connected to USB full speed DAC via USB2ISO (it is full-speed also).
Wifi didn't make any problems.

When I connected high-speed async DAC the problem with USB port stayed till the WiFI was disabled.
If I connected the high-speed DAC via USB2ISO the problem was also gone.

The async high-speed DAC is self powered.

It seems to me the problem is not only with full speed USB devices.

What is USB2ISO? Is it this device?
http://electronics-shop.dk/?id=1038

It looks like this adapter is full-speed only (12 Mbps only), so using it with high-speed devices (480 Mbps) may lead to unpredictable results.

And what are the DAC you are talking about?

If they are using isochronous USB transfer (either at full or high-speed), then it will not cause the problem, which is the USB hanging but the router still working (not rebooting) after between 1 minute and 1 hour. This problem has been reported to occur with USB synchronous transfer only.

It looks like your problem is more related to the USB2ISO adapter not able to keep up at high-speed, and specifically picking up WiFi spurious emissions with its integrated isolation transformer coils.

There have been no problems with adaptive full speed DAC connected to USB port directly pr via ISO2USB.

Squonk - the ISO2USB is the one you mentioned.

The problems occur with the second DAC, which is highspeed and async.
This DAC works without problems if Wifi on the router is turned off.
If I turn on the Wifi, the DAC reconnects for a few times, and is then unable to connect again.

I have used the async highspped DAC on Asus WL-500gP v1 - no problems and also on laptop with three different Linux distros - also no problems.

So I guess there is something special in this AR9331 router.

Probably also on other AR9331-based routers, too, as it has been observed already.

I thought that problems with USB are valid only for fullspeed USB devices, that is why I posted the problem with a highspeed device,

As I said, I suspect your problem may be caused by the isolation transformers picking up spurious WiFi emissions from the AR9331.

Is it possible to increase the distance between the router and the USB2ISO device to check?

Anyway, the USB2ISO is full-speed only, and using it with high-speed devices is not guaranteed.

I read on the mod forums for tp-links that the problem with AR9331's usb was with USB1, wheras USB works fine.
I also read that someone contacted Atheros and said it's not fixable. If you want to connect USB 1.x devices then use a decent USB 2.0 hub that has a transaction translator on it.

I'm working on a new usb mod for a TP-Link WRT702N that uses a zenner to provide the 5 v, and I'll update the forum when it's done.

Cheers. Oh and if you don't have the full datasheet (100 something pages) I can send it on to anyone who P.M.s me.

(Last edited by hojuruku on 20 Mar 2013, 04:49)

Squonk -

I am not using the highsped async DAC with USB2ISO

I only tested it once, and the high speed DAC switched to adaptive mode - I guess because USB2ISO is full speed only.

The problems with highspeed async DAC appears also when it is connected directly to USB port on MR3220 v2, and that eliminates Wifi emitions imposed on USB2ISO coils.

And the highspeed async DAC is self powered.

Thanks for all the help till now.

(Last edited by davor128 on 20 Mar 2013, 12:07)

Ok,so this is not a direct RF emission problem.

Can you check how the DACs are enumerated into dmesg (i.e. full or high-speed) when connected directly to the router?

Then we have to figure out if the transfer is synchronous or isochronous (= async?).

DAC is enumerated as highspeed.

It is also put in the asynchronous mode.

When Wifi is turned off, it works fine (apart from the alsa 1.0.24 problem...which is not the same subject)

When Wifi is turned on it stays connected, but when DAC is accessed via mpd or cat /proc/card/stream0
t stays connected for a short time and then reconnects two or three times and is then unable to connect to USB - as was mentioned for some other USB devices on this thread.

P.S.
Have some questions concerning alsa-lib 1.0.24/1.0.25 for openwrt, but don't know where to put it.

re: alsa-lib
is it "how do I get it working?": in Discussion
is it "I know it should work, and my guess as to why it doesn't is": in Developer

alsa-lib
The question is how to enable alsa-lib 1.0.25 in Attitude Adjustemnt.

1.0.24 is currently built for AArc1
If you need the newer, I suggest building your own off trunk or AArc1
Be prepared for "dev" issues though. That's when you need to post in the dev section.
Good luck.

I know alsa-lib is off topic here, but in case someone is interested -

https://dev.openwrt.org/ticket/13223

I'm knee deep in bringing up FreeBSD-10 on the AR933x (in my spare time, not my work time) so I've been interested in the issues people have faced with this chip.

So what's happening is this:

* There's only an EHCI interface;
* There's an internal hub that is supposed to handle the low speed stuff, so all that we need to do is speak to the EHCI interface - that way we don't need both OHCI and EHCI like in previous chips;
* God knows why things are going crazy when this fails.

Has someone created an openwrt bug for this? If so, I can kick it around internally and see if there's a known work around or a more definitive answer that can be shared.

.. also if you have a datasheet, please poke me privately (adrian@freebsd.org.) I work there so I am *cough* allowed to have such things. I'd just like to be on the same page so to speak.

Thanks!

AR9331 datasheet
Link are taken from Wiki

You can try filling in a bug report if you want, but don't expect too much: in order to fix it, this kind of bug requires having a high-end USB protocol analyzer and sitting in front of a router with an Arduino board spitting a counter on CDC-ACM every second for up to an hour to see what is going on.

As described previously, it looks like it is related to WiFi and not to a power supply issue, so you can expect some interaction with the radio emissions, which would require some even more expensive tools to observe (like a 9 GHz spectrum analyzer...).

If you have such tools (and knowledge), I am ready to help you to investigate on this point!

There's odd Ar933x USB PLL and calibration code in the reference wifi driver. It's possible that may help.

github.com/qca/ - look at the openhal project, in hal/ar9300. Grep for 'usb'. See random USB calibration code hiding in there. Wonder why the hell it's there.

Interesting!

I see 2 different things in there:

• https://github.com/qca/qcamain_open_hal … eset.c#L76

  This is a WAR (work around) for usb offload solution. IIRC, it has been tested unsuccessfully previously in this thread:
  https://forum.openwrt.org/viewtopic.php … 31#p182631

• https://github.com/qca/qcamain_open_hal … om.c#L1239

  It looks like there is a calibration value (0, 1, 3, 7 or 15) loaded from OTP @ offset 0x14 or 0x04 to set the AR_PHY_CTRL2_TX_MAN_CAL register. Maybe this magic would help us?

I'll ask around tomorrow and see what I can dig up.

You could try changing the tx power of the radio, or maybe print out when it's doing wifi or regulator programming; see if anything coincides with USB going all kooky.

I have been reading through and  I am debugging what appears to be the same problem.  I have 2 different AR9331 based systems here,  one with a single, direct to CPU USB port and another with an onboard powered hub to provide extra ports (Alfa Hornet + another Alfa design).  On both, a busy USB disconnects when the WLAN interface is also busy.  I tried both of the fixes listed above by @Squonk with no change.  I have tested it on the LSDK 9.2.0_U10.1020 source and also on a pretty stock linux-3.8,  both exhibit the same problem.

It seems that the problem only occurs after I set an SSID,  so scanning for networks is fine,  but once I have set an SSID the USB disconnects (if its busy). If the USB is idle or the WLAN is idle,  all seems fine,  its only once you get them both busy with tasks like network traffic and file transfers that the USB gets disconnected.

Right now I am trying through other avenues to find someone who can confirm that it is possible to have both the WLAN and USB ports busy on this SOC  using either some other version of the drivers/linux or a completely different OS.  That would point to a SW issue and mean the problem can be solved or worked around.  So if anyone feels their AR9331 platform can do this fine please let me know and I'll provide a really simple test to confirm it works :-)

The other avenue is to see what is happening with a USB analyser.  Unfortunately I don't have access to one of those :-)  Having looked at the USB lines with a probe there doesn't seem to be any "additional" induced noise when the WLAN is active,  so it doesn't seem to be cross talk or interference,  but I wouldn't rule it out.  DMA is another area that is shared
and might be related to the problem.

Like others,  I have also tested with external powered and unpowered hubs,  no change.

Anyway,  if anyone has any ideas they would like to see me try I am open to suggestions as I am actively trying to resolve this issue, thanks.

hello @david-m,

we have a product based on the alpha hornet board.. the very first post in this thread was observed using that board.  In our experience all USB 1.1 issues go away when using a USB 2.0 HUB.  We can run PPPD over a USB 1.1 Modem while using WiFi without issue as long as there is a HUB in between.  As soon as the HUB is removed the USB hangs up and needs to be reset by removing and reinserting the USB device.    Interestingly enough the USB 1.1 devices work fine when directly connected to the board when the WiFi is disabled.

currently running 34332 on the hornet.

take care.

--luis

Thanks @lsoltero,  I wasn't sure from reading through the thread that the hub fully solved the issue, its seems it didn't work for everyone. I will retest the hornet with an external hub and see what happens.