MUSB + low speed device

Does the AM3505 host have the required 120uF capacitance on VBUS?

I'm not familiar with the EVM in this case, but typically there is a jumper that switches VBUS capacitance from Device mode (10uF max) to Host mode (120uF min).

Hi Dk,

thanks for your reply. Actually on evm a 150uF cap is not populated near the otg connector, and this explains VBUS drops with some devices. I'll check driver behaviour after adding proper capacitor.

On our target we do have 100u+47u on the vbus and the problem still happens.

Regards,

E

Enrico,

I may have made an incorrect assumption in my initial post. Are you using the affected port in OTG mode or do you have the ID pin grounded?

Hi,

the ID pin is grounded by a jumper on the evm, while on my target it's tied to ground, so I'm working in host mode.

EVM: I just now mounted a 220uF on the EVM and it seems to solve the issue as you expected, both with 2.6.37 and 2.6.33-rt kernel.

TARGET: Right now I'm increasing the 150uF with further 220uF, and I'll let you know. I'm sure that if the vbus drop is solved the connection should work fine, as we already have with lot of peripherals.

E

Based on the nature of your failure and the results of the workaround that resolved it, my hypothesis is that the problem devices you are encountering have an excessive amount of capacitance on VBUS. The inrush current caused by this excessive capacitance is likely causing the host VBUS rail to droop which triggers the VBUS low interrupt.

The USB specification states that a device may not present a load greater than 10uF in parallel with 44 Ohms to prevent this exact situation from occurring.

Hi DK,

EVM behavious with 220u seems correct with standard 2.6.37 kernels, but I've got again enumeration failures both with EVM and my target where I'm running 2.6.33.7-rt29 kernel.

From last debug tests VBUS low interrupt seems not to occur (I added further 220uF to the already mounted 147uf), but khubd thread often time out during descriptor fetch:

often we also have erorr on port reset, as you can see from two log excerpt below.

It seems some timing issues or hub reset code could prevent communication success with this LS device

Please note that with WCE on the same platform there are no HID device errors.

LOG 1:

hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002

hub 2-0:1.0: port 1, status 0301, change 0001, 1.5 Mb/s
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
usb 2-1: new low speed USB device using musb_hdrc and address 29
usb 2-1: khubd timed out on ep0out len=0/0
usb 2-1: khubd timed out on ep0out len=0/0
usb 2-1: device not accepting address 29, error -110
usb 2-1: new low speed USB device using musb_hdrc and address 30
usb 2-1: khubd timed out on ep0in len=0/64
usb 2-1: khubd timed out on ep0in len=0/64
# usb 2-1: device descriptor read/64, error -110
usb 2-1: device descriptor read/64, error -110
usb 2-1: device not accepting address 31, error -110
usb 2-1: device not accepting address 32, error -110

LOG 2:

[ 1083.222259] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 1083.222320] hub 2-0:1.0: port 1, status 0301, change 0003, 1.5 Mb/s
[ 1083.325714] hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
[ 1083.427703] usb 2-1: new low speed USB device using musb_hdrc and address 49
[ 1083.485717] hub 2-0:1.0: port 1 not reset yet, waiting 50ms
[ 1083.536712] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1083.737701] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1083.938690] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1083.938720] hub 2-0:1.0: port_wait_reset: err = -16
[ 1083.938751] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1084.139709] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1084.340728] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1084.541717] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1084.541748] hub 2-0:1.0: port_wait_reset: err = -16
[ 1084.541778] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1084.742736] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1084.943725] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1085.144714] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1085.144744] hub 2-0:1.0: port_wait_reset: err = -16
[ 1085.144744] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1085.345703] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1085.546722] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1085.747711] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1085.747741] hub 2-0:1.0: port_wait_reset: err = -16
[ 1085.747741] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1085.948730] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1086.119445] musb_h_ep0_irq 1119: no URB for end 0
[ 1086.149780] hub 2-0:1.0: unable to enumerate USB device on port 1
[ 1086.156250] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0002
[ 1086.156311] hub 2-0:1.0: port 1, status 0301, change 0003, 1.5 Mb/s
[ 1086.259704] hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x301
[ 1086.361694] usb 2-1: new low speed USB device using musb_hdrc and address 50
[ 1086.419708] hub 2-0:1.0: port 1 not reset yet, waiting 50ms
[ 1086.470703] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1086.671691] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1086.872711] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1086.872741] hub 2-0:1.0: port_wait_reset: err = -16
[ 1086.872772] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1087.073699] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1087.274688] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1087.475708] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1087.475738] hub 2-0:1.0: port_wait_reset: err = -16
[ 1087.475738] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1087.676696] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1087.877685] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1088.078704] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1088.078735] hub 2-0:1.0: port_wait_reset: err = -16
[ 1088.078735] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1088.279693] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1088.480712] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1088.681701] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1088.681701] hub 2-0:1.0: port_wait_reset: err = -16
[ 1088.681732] hub 2-0:1.0: port 1 not enabled, trying reset again...
[ 1088.882690] hub 2-0:1.0: port 1 not reset yet, waiting 200ms
[ 1089.129638] musb_h_ep0_irq 1119: no URB for end 0
[ 1089.135162] usb 2-1: device descriptor read/64, error -19
[ 1094.241790] usb 2-1: khubd timed out on ep0in len=0/64
[ 1104.292755] hub 2-0:1.0: unable to enumerate USB device on port 1
[ 1107.318664] hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
[ 1110.242828] hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
[ 1113.166656] hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
[ 1116.090667] hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?
[ 1116.098602] hub 2-0:1.0: unable to enumerate USB device on port 1

--------------------

Hi DK,

MUSB driver code has been quite revised from revision 2.6.32 to 2.6.37 but from release notes of related PSP it seems there are no bugfixes or known issues with HOST mode.

I've performed bit of testing on EVM, with 2.6.32, 2.6.37 and 2.6.33.7-RT, and all but the latest seems to work fine with the critical LS device.

A code comparison between 2.6.32 and 2.6.33-RT shows that hub code for this version is the same of 2.6.37's.

So it seems rather a timing issue with RT extension instead of a code problem, but this is the version I need for performance requirements.

I'll dig into hub init and enumeration stage code.

E

Hi,

I've done further tests both on EVM and on my target. Actually I have connection errors regardless of kernel revision and RT extension.

When the device can't be enumerated we have a VBUS low detection:

[ 3313.239410] am3517_interrupt 755: VBUS on (a_wait_vrise), devctl 09
...

[ 3313.417877] musb_stage0_irq 659: CONNECT (a_host) devctl 3d
...

[ 3313.654418] musb_port_reset 168: root port reset stopped
[ 3313.660034] musb_hub_control 356: port status 00120303
[ 3313.665832] am3517_interrupt 755: VBUS off (b_idle), devctl 98
...

[ 3313.761505] usb 2-1: new low speed USB device using musb_hdrc and address 4

So again it's related to device inrush current and power up.

I never detect a VBUS_ERROR condition (see am3517.c and musb_core.c comments) but only a VBUS LOW.

It's a fact that with the RT extension the rate of failure is much higher than with the standard kernel, so it seems related with connection event latency.

Have you got any hints to filter out this voltage drop spikes?

Thanks

Hi,

I've done several tests with EVM: once we have the VBUS capacitor the detection error rate still remains veri high with kernel 2.6.32 e 2.6.33.7-rt.

Just after port_reset we have a DRVVBUS irq with drvvbus low detection, port power disable and subsequent communication error at hub layer:

-------------------

[  458.775177] am3517_interrupt 755: VBUS on (a_wait_vrise), devctl 09
[  458.781494] musb_interrupt 1577: ** IRQ peripheral usb0000 tx0001 rx0000
[  458.788238] musb_g_ep0_irq 643: csr 0000, count 0, myaddr 224, ep0stage setup
[  458.940307] musb_interrupt 1577: ** IRQ host usb0010 tx0001 rx0000
[  458.946533] musb_stage0_irq 423: <== Power=e0, DevCtl=3d, int_usb=0x10
[  458.953094] musb_stage0_irq 659: CONNECT (a_host) devctl 3d
[  458.958709] musb_h_ep0_irq 1061: <== csr0 0800, qh (null), count 0, urb (null), stage 1
[  458.966766] musb_h_ep0_irq 1119: no URB for end 0
[  458.971649] musb_hub_control 356: port status 00010301
[  458.976806] musb_hub_control 290: clear feature 16
[  458.981689] musb_hub_control 356: port status 00000301
[  459.024932] musb_hub_control 356: port status 00000301
[  459.063995] musb_hub_control 356: port status 00000301
[  459.103057] musb_hub_control 356: port status 00000301
[  459.142120] musb_hub_control 356: port status 00000301
[  459.147338] musb_hub_control 426: set feature 4
[  459.212463] musb_port_reset 168: root port reset stopped
[  459.217803] musb_hub_control 356: port status 00120303
[  459.223022] am3517_interrupt 755: VBUS off (b_idle), devctl 98
[  459.228881] musb_interrupt 1577: ** IRQ peripheral usb0004 tx0001 rx0000
[  459.235626] musb_stage0_irq 423: <== Power=e0, DevCtl=98, int_usb=0x4
[  459.242095] musb_stage0_irq 682: BUS RESET as b_idle
[  459.247100] musb_g_reset 2015: <== B-Device addr=e0 driver 'g_ether'
[  459.253479] musb_g_disconnect 1961: devctl 98
[  459.257873] musb_g_ep0_irq 643: csr 0000, count 0, myaddr 240, ep0stage setup
[  459.321807] musb_hub_control 290: clear feature 20
[  459.326629] usb 2-1: new low speed USB device using musb_hdrc and address 13
[  459.333770] musb_hub_control 426: set feature 4
[  459.399932] musb_hub_control 356: port status 00020213
[  459.462402] musb_hub_control 356: port status 00020213
[  459.673370] musb_hub_control 356: port status 00020213
[  459.884307] musb_hub_control 356: port status 00020213
[  459.889465] musb_hub_control 426: set feature 4
[  460.103118] musb_hub_control 356: port status 00020213
[  460.313964] musb_hub_control 356: port status 00020213
[  460.524932] musb_hub_control 356: port status 00020213
[  460.530120] musb_hub_control 426: set feature 4
[  460.743682] musb_hub_control 356: port status 00020213
[  460.954650] musb_hub_control 356: port status 00020213
[  461.165557] musb_hub_control 356: port status 00020213
[  461.170745] musb_hub_control 426: set feature 4
[  461.384338] musb_hub_control 356: port status 00020213
[  461.595245] musb_hub_control 356: port status 00020213
[  461.806182] musb_hub_control 356: port status 00020213
[  461.811370] musb_hub_control 426: set feature 4
[  462.024963] musb_hub_control 356: port status 00020213
[  462.235931] musb_hub_control 356: port status 00020213
[  462.446807] musb_hub_control 356: port status 00020213
[  462.451965] hub 2-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?

-------------------

I NEVER receive a VBUS_ERROR interrupt (I see a dedicated workaround for this event), but only a DRVVBUS irq.

With  2.6.37 kernel failure rate is MUCH lower. But when the problem arises, the log is the same: DRVVBUS irq after port reset and drvvbus low detection.

Hardware dependency is clear, but I think interrupt handling and/or hub layer affect error rate.

At lower level I've seen that from 2.6.32 to 2.6.37 interrupt service sequence has changed (am3517_interrupt + musb-interrupt stage0+stage2 vs am35x_interrupt + musb_interrupt stage0, stage2 isr moved).

I'll try a merge but can be here the root cause of the different detection failure rate?

Please note that I never receive a VBUS_ERROR condition due to voltage drop on VBUS.

Thanks and regards.

Hi Enrico,

Is the enumeration issue only happened with some Low-speed devices? Have you tried with any High-speed device?

Where did you get the 2.6.37 kernel from? Is it TI PSP kernel? If not, is it possible you try with git://arago-project.org/git/projects/linux-omap3.git (branch origin/OMAPPSP_04.02.00.07), which is the latest kernel TI supports on AM35x? I am not expecting the issue will disappear with this Arago kernel, but at least we are on the same s/w base to investigate the issue.

Do you have access to a USB protocol analyzer to capture the enumeration trace?

Hi Bin, thanks for your support.

Yes, the enumeration issue happens with some low speed keyboard: with HS mass storage and other peripherals everything seems fine. Some other LS keyboards work fine too.

So, it seems highly dependent on hardware: maybe these consumer device are not fully usb compliant, or at least they're 'border-line' for supply parameters.

Anyway, they work with desktops and other standard hosts.

1. I'm using TI kernel from ti-sdk-am3517-evm-05.04.00.00/board-support/linux-2.6.37-psp04.02.00.07.sdk.

2. 2.6.32 tests performed with arago repos 2.6.32 tagged tree.
3. 2.6.33.7-rt29 again from arago repo.

As from my previous post, failure rate with 2.6.37 kernel is very low (i.e. the keyboard works almost everytime, and enumeration failure is really rare). If I reach this result on rt kernel I think the host support can be accepted by the customer.

With 2.6.32 and 2.6.33 instead often there's a DRVVBUS irq occurring after initial port reset: during testing on my target I added really long delays after connection event, so VBUS should be very stable when resetting the port.

Further question: I noticed that with 2.6.37 there's no DRVVBUS interrupt when unplugging the device, is this correct? With older kernels I always get this irq when disconnecting  a device.

I'm working with OTG mode, ID pin tied to GND, with all the three version.

At the moment I don't have a usb analyzer, but the issue comes usually before any data communication (i.e. before descriptor fetching).

Thanks again for your kind support.

Thanks for the explanation.

I assume you have to use the 2.6.33 RT patch and unable to move to 2.6.37 kernel, is it correct? I did a quick check, there is roughly about 600 patches on USB from .32 to .37 kernel on Arago. I think it probably takes some effort to narrow down to the root cause.

Which tag do you use for testing 2.6.32 kernel? I will try what I can find from there.

Hi Bin,

you're right, I need RT kernel. At the moment I've got two main issues with this version: this one with usb host support and another I'm still working: the system often crashes with an oops when halting the system, and it seems due to net driver/subsystem. I've got to debug deeply this failure that happens only with the RT kernel.

Back to the USB issue...I use 2.6.32 arago commit 627293ad28604b22612f9a4a318f64cfab241e22, tag v2.6.32_OMAPPSP_03.00.01.06.

>> I did a quick check, there is roughly about 600 patches on USB from .32 to .37 kernel on Arago. I think it probably takes some effort to narrow down to the root cause.

I've seen, and that's why I'm asking hints where to focus on. Please note that the main issue seems related with the DRVVBUS interrupt and not with data communication/ dma, ecc.

I was focusing my attention on isr routine and init code, but also musb core/ control thread could lead to this difference.

Thanks again,

E

Enrino,

enrico benetti said:

[  459.228881] musb_interrupt 1577: ** IRQ peripheral usb0004 tx0001 rx0000

Interrupt 0x0004 is Babble, that is why VBUS is turned off.

I will try if I can workaround this Babble issue. Please give me some time. I will keep you posted.

The EVM in the link http://www.logicpd.com/products/system-on-modules/zoom-am3517-evm// is the only AM35x EVM I am aware of. Are you referring to this one? You mentioned there is a jumper for the ID pin on the EVM, but this EVM in the link does not have a jumper, its ID pin is connected to the mini-AB receptacle.

When the enumeration issue happens, if you keep the mouse/keyboard plugged, and do command 'echo F > /proc/driver/musb_hdrc', does the device got enumerated then? or the Babble interrupt still happens?

If doing 'echo F > ...' command makes the USB device enumerated, please use the attached patch below. It detects the Babble interrupt and re-enumerate the device.

diff --git a/drivers/usb/musb/am3517.c b/drivers/usb/musb/am3517.c
index e7922aa..5f46626 100644
--- a/drivers/usb/musb/am3517.c
+++ b/drivers/usb/musb/am3517.c
@@ -634,6 +634,7 @@ static irqreturn_t am3517_interrupt(int irq, void *hci)
 	irqreturn_t ret = IRQ_NONE;
 	u32 pend1 = 0, pend2 = 0, tx, rx;
 	u32 epintr, usbintr, lvl_intr;
+	u8  is_babble = 0;
 
 	spin_lock_irqsave(&musb->lock, flags);
 
@@ -699,6 +700,20 @@ static irqreturn_t am3517_interrupt(int irq, void *hci)
 			(usbintr & USB_INTR_USB_MASK) >> USB_INTR_USB_SHIFT;
 		/* musb->int_regs = regs; */
 	}
+
+	if ((musb->int_usb & MUSB_INTR_BABBLE) && is_otg_enabled(musb)
+		&& (musb->xceiv->state == OTG_STATE_A_HOST))
+		is_babble = 1;
+	else if ((musb->int_usb & MUSB_INTR_BABBLE) && !is_otg_enabled(musb)
+		&& is_host_enabled(musb))
+			is_babble = 1;
+
+	if (is_babble) {
+		musb->int_usb = MUSB_INTR_DISCONNECT;
+
+		ERR("CAUTION: musb: Babble Interrupt Occured\n");
+	}
+
 	/*
 	 * DRVVBUS IRQs are the only proxy we have (a very poor one!) for
 	 * AM3517's missing ID change IRQ.  We need an ID change IRQ to
@@ -800,6 +815,13 @@ static irqreturn_t am3517_interrupt(int irq, void *hci)
 			DBG(2, "Spurious IRQ, CPPI 4.1 status %08x, %08x\n",
 					 pend1, pend2);
 	}
+
+	if (is_babble) {
+		musb_writeb(musb->mregs, MUSB_DEVCTL,
+			musb_readb(musb->mregs, MUSB_DEVCTL) |
+			MUSB_DEVCTL_SESSION);
+	}
+
 	return ret;
 }
 

It may not fix the 'read descriptor error' you mentioned above though.

Hi Bin,

thanks for your support.

Let me answer your questions:

1. the EVM I'm referring to is the Logic one you pointed, the grounded ID pin was just patched by me.

2. plugging the 'tricky' device I'm almost never able to enumerate it when the issue happens: once I receive babble interrupt I can retry several time issuing 'echo F ....' without succeding.

If I remove this device and plug another (known to be working) one the system always goes fine and detects it.

3. applying your patch the issue seems solved both on EVM and on my customer's target with 150uF on VBUS and further 220uF on usb connector pins.

Keyboard enumeration fails but after one or often several retries it's detected successfully. So it seems to solve in these cases.

4. I removed the additional 220uF (so back to production configuration for the target with 150uF on VBUS) and enumeration fails everytime: I always loop into Babble error and never succeed in getting the descriptor...

So, again it's a hardware dependent issue (device and host), but I wonder why with Windows CE bsp  this issue never arises on this target.

There's something related with reset timings and so on, I suppose. Actually I suppose VBUS pcb layout is weak on the target too.

Basically it seems solved on the EVM.

Best regards,

E

Anyway Bin let me perform further tests with this version and I'll let you know.

E

Hi Bin,

I had further test session with this patch but again it could happen that the enumeration stage loops with babble errors, thus not being able to complete the descriptor retrieval.

Anyway we're thinking to move to kernel 3.2.x+rt because of other stabilty issues we have with 2.6.33.7+rt29.

Best regards,

Enrico

Enrico,

Thanks for the update.

Where is the 3.2.x kernel for AM35x come from? I am not aware of any 3.2 support on AM35x from TI, and wondering if MUSB is fully enabled in that kernel.

Hi Bin,

we think of mainline 3.2.43 and/or TI 3.2.0 for AM335x controllers, but we have to investigate on feasibility of this porting. Are you aware of any repo/projects of mainline kernel on AM35xx?

For sure it should be better to fix current 2.6.33.7.

I've quickly checked for omap2plus arch support, but I can suppose that usb or other subsystems could have issues or partial porting.

I'll let you know how our internal discussion goes on, but I'd obviously appreciate any advice.

E

Enrico,

I am not aware of any non-TI kernel support for AM35x. I quickly checked mainline v3.2, it does not have CPPI DMA support in MUSB driver, so you at least either have to port CPPI DMA driver, or use PIO mode if USB throughput requirement is not high.

Anyway, I guess you are evaluating AM35x and AM335x from both HW and SW perspective to make the decision.

Please let us know whatever we can help.

Hi Bin,

we should fix the current kernel release.

Have you got any other hints on possible way to deal with babble errors during reset//enumeration, and why behaviour from 2.6.32 and 2.6.37 has changed? I think it could be related with interrupt handling, but I can't figure out which is the right fix

Other than usb-otg  issue with LS device, I've got a random crash that often happens while booting or shutting down the system:

could you have a look at this post 

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/255270/936608.aspx#936608

In the meanwhile I'll try to further debug the system.

Thanks in advance,

E

Enrico,

The driver has many changes between 2.6.33 and 2.6.37, it is hard to narrow down what change makes 2.6.37 better and back port it to 2.6.32.

Have you done USB Eyediagram test and does it look good?

Have you follow the USB layout guidance to improve the signal integrity?