AM1808: USB0_DRVVBUSn drive to LOW sometimes

Tony Tang

Part Number: AM1808
Other Parts Discussed in Thread: STRIKE, OMAPL138

This is a mature product of customer, Recently they sell it to oversea customer, the end customer report sometimes the USB connected scanner doesn't work, field check found the USB0_DRVVBUS is LOW, so no 5V on USB0_VBUS, then the connected scanner doesn't work.

The end customer bought 50 set equipment, most of them report such issue from time to time.

The usually use case is connecting the USB scanner, finish some job, put it aside or move to next room to charge the battery without power off the machine, when use it again, the scanner doesn't work, but other feature is normally, the AM1808 is running, if power cycle the machine/AM1808, it resume. Seems the USB0 module hanged.

The USB0_ID is pulled down to GND with 0ohm resistor.

Question: What condition will result in such issue? as it is not reproduced in customer lab yet, What kind of information can help to debug the issue? if needed customer will try to capture more detail information including log, register value etc please give some clue.

Customer did some experiments in lab try to reproduce the issue, but did not reproduce.

#1. After power up the works, decrease USB0_VBUS < 4.4V, USB0_DRVVBUSn output did not change, still is high.

#2. Keep USB0_VBUS<4.4V during power up, USB_DRVVBUS is high.

over 6 years ago

0 Yordan Kovachev over 6 years ago

TI__Guru**** 161600 points

Hi Tony,

Is it possible to provide the value of CFGCHIP2 register? And maybe their bootlog. Also can they verify that PHY initialization follows the description in Section 34.2.4 USB PHY Initialization of the device TRM?

Also are they seeing any kind of error on their console (dmesg), when USB0 hangs? If yes, can you share the log?

Best Regards,
Yordan

0 Tony Tang over 6 years ago in reply to Yordan Kovachev

TI__Mastermind 25206 points

Yohan,

Yordan Kovachev said:
Is it possible to provide the value of CFGCHIP2 register?

I will let customer do.

Yordan Kovachev said:
And maybe their bootlog. Also can they verify that PHY initialization follows the description in Section 34.2.4 USB PHY Initialization of the device TRM?

This is Linux system, the initialization is part of Linux driver, I don't think customer touched it.

Yordan Kovachev said:
Also are they seeing any kind of error on their console (dmesg), when USB0 hangs? If yes, can you share the log?

I will let customer do.

0 Yordan Kovachev over 6 years ago in reply to Tony Tang

TI__Guru**** 161600 points

Hi Tony,

In addition, regarding the connection of DRVVBUS, in my experience with sitara (am335x) devices, I've seen the following implementation on the switch side:

This is from sitara devices, but I think this may be similar in AM1808.

Also have they checked all the eratas for USB:

Best Regards,
Yordan

0 Tony Tang over 6 years ago in reply to Yordan Kovachev

TI__Mastermind 25206 points

Yordan

Yes, The 5V VBUS is controlled by USB0_DRVVBUS, the USB0_DRVVBUS is a output IO pin of USB0. now the problem is we don't know when and why the USB0_DRVVBUS output LOW as the ID pin is pulled low, it is HOST only mode.

0 Yordan Kovachev over 6 years ago in reply to Tony Tang

TI__Guru**** 161600 points

Hi Tony,

Sorry, maybe I didn't ask my question correctly:

The 5V VBUS is controlled by USB0_DRVVBUS, the USB0_DRVVBUS is a output IO pin of USB0

I meant do you have the pulldown on USB0_DRVVBUS as in the above schematic (from AM335x GP EVM, same implementation, but for USB1_DRVVBUS, on StarterKit & BBB).

Best Regards,
Yordan

0 Tony Tang over 6 years ago in reply to Yordan Kovachev

TI__Mastermind 25206 points

Yordan,

Below is customer's implementation, I found some violation of added pull down resistor on DP/DM, but I am not sure whether the problem related to it, I suppose it may impact the signal quality then stability. but may not result in USB change mode from host to device by output DRVVBUS low.

0 Tony Tang over 6 years ago in reply to Yordan Kovachev

TI__Mastermind 25206 points

Yordan,

Customer get registers dump as below picture, the CHIPCFG2 value did not change. there are some other register value changed, would you please help to analysis?

0 Yordan Kovachev over 6 years ago in reply to Tony Tang

TI__Guru**** 161600 points

Hi,

Sorry for the delayed reply. I'll take a look & update.

Best Regards,
Yordan

0 Tony Tang over 6 years ago in reply to Yordan Kovachev

TI__Mastermind 25206 points

Yordan,

We realize it should relate to USB babble interrupt issue. it is fixed by Linux patch for AM335x. but I did not find such patch for AM1808 Linux SDK.

We need help on how to fix the USB babble issue in the old Linux kernel? customer use 2.6.33 version kernel SDK/PSP

0 Mukul Bhatnagar over 6 years ago in reply to Tony Tang

TI__Guru* 78305 points

Hi Tony
Capturing some key points from the internal discussion you have had with the USB experts

Kernel v2.6.33, is very old . Is it possible the customer to migrate to the latest Processor SDK v4.0, which supports AM1808/OMAPL1-138?

In general, to recover from the babble condition, the babble interrupt handler has to
- Reset the musb controller;
- Re-configure the controller, such as endpoints and fifo;
- Enter host mode;

But the code change is not that trivial if it is not in 2.6.33.

Regards
Mukul

0 Tony Tang over 6 years ago in reply to Mukul Bhatnagar

TI__Mastermind 25206 points

Mukul,

As this is a mature product MPed for several years, it is almost not possible for customer to upgrade the whole software system.

Customer tried to follow those steps in babble interrupt handler, but it doesn't works. maybe the operation is not right, so need BU provide more detail procedure. especially for step 2, which registers need to reconfigure, and the which first, which after.

Customer tried to reinstall USB driver after issue happen, it can recover the USB, but it consume long time, it is not good for end customer use experience. so hope to recover it in babble handler, it should be more efficient.

0 Mukul Bhatnagar over 6 years ago in reply to Tony Tang

TI__Guru* 78305 points

Hi Tony
Can you share the customer code on what they tried?

How are they reseting the MUSB controller?

Can we also see if doing a USB PSC reset helps?

Regards
Mukul

0 Tony Tang over 6 years ago in reply to Mukul Bhatnagar

TI__Mastermind 25206 points

Mukul,

For the 3 steps, it is easy to do #1, #3 to reset and restart session. But for step #2 Re-configure the controller, such as endpoints and fifo; it is not easy to do under Linux, it is system call, customer studied AM335x USB babble patch, which is Linux kernel V3.2, the system call API is different, customer can't refer it to implement in Kernel V2.6.33

So the problem is don't know how to reinitialize USB configure registers under Linux V2.6.33, so PSC reset should not help.

0 Mukul Bhatnagar over 6 years ago in reply to Tony Tang

TI__Guru* 78305 points

Thanks Tony understood.
Since the customer has already reviewed AM335x v3.2 kernel, but is unable to backport it to 2.6.33 due to the usb framework difference. It maybe best that we refer them to some 3p that they could engage to do this porting effort.
We will not be able to help on a one off migration effort for an older kernel.

0 Tony Tang over 6 years ago in reply to Mukul Bhatnagar

TI__Mastermind 25206 points

Bin, Mukul,

Customer captured register INTRUSB = 0x0C after failure, bit 2 RESET_BABBLE is set.

0 Mukul Bhatnagar over 6 years ago in reply to Tony Tang

TI__Guru* 78305 points

Thanks for confirming this Tony

0 Tony Tang over 6 years ago in reply to Mukul Bhatnagar

TI__Mastermind 25206 points

Today we reproduced the failure with ESD strike on both LCDK with latest Processor SDK and old PSP SDK on Logicpd board, but USB did not recover on both

on LCDK with processor SDK, dumped USB register as below:

root@omapl138-lcdk:/sys# cat kernel/debug/musb-hdrc.1.auto/regdump
MUSB (M)HDRC Register Dump
FAddr : 00
Power : e0
Frame : 0295
Index : 03
Testmode : 00
TxMaxPp : e000
TxCSRp : 0000
RxMaxPp : 0000
RxCSR : 001f
RxCount : 001e
IntrRxE : 001e
IntrTxE : 001f
IntrUsbE : f7
DevCtl : 80 //Before failure, it is 5d.
VControl : 00000000
HWVers : 0000
LinkInfo : 5c
VPLen : 3c
HS_EOF1 : 80
FS_EOF1 : 77
LS_EOF1 : 72
SOFT_RST : 00
DMA_CNTLch0 : 0000
DMA_ADDRch0 : 00000000
DMA_COUNTch0: 00000000
DMA_CNTLch1 : 0000
DMA_ADDRch1 : 00000000
DMA_COUNTch1: 00000000
DMA_CNTLch2 : 0000
DMA_ADDRch2 : 00000000
DMA_COUNTch2: 00000000
DMA_CNTLch3 : 0000
DMA_ADDRch3 : 00000000
DMA_COUNTch3: 00000000
DMA_CNTLch4 : 0000
DMA_ADDRch4 : 00000000
DMA_COUNTch4: 00000000
DMA_CNTLch5 : 0000
DMA_ADDRch5 : 00000000
DMA_COUNTch5: 00000000
DMA_CNTLch6 : 0000
DMA_ADDRch6 : 00000000
DMA_COUNTch6: 00000000
DMA_CNTLch7 : 0000
DMA_ADDRch7 : 00000000
DMA_COUNTch7: 00000000
ConfigData : 00
BabbleCtl : 00
TxFIFOsz : 05
RxFIFOsz : 05
TxFIFOadd : 0108
RxFIFOadd : 0108
EPInfo : 44
RAMInfo : 0a
root@omapl138-lcdk:/sys#

root@omapl138-lcdk:/sys# devmem2 0x01e0040a
/dev/mem opened.
Memory mapped at address 0xb6f2a000.
Read at address 0x01E0040A (0xb6f2a408): 0xF700001E
root@omapl138-lcdk:/sys#

Is the babble recover mechanism enabled in the default omapl138-lcdk-linux-04.00.00.04.img?

0 Bin Liu over 6 years ago in reply to Tony Tang

TI__Guru*** 125136 points

Tony,

It appears the babble condition is not identified properly in the Processor SDK v4.0.0.4 kernel for omapl138. I am working on solving the bugs.

What I can tell now is that the babble recover mechanism itself in TI v4.9 kernel does work for omapl138, the sw bugs sit in the logic of identifying babble condition. While I am working on solving the bugs, I think you can let the customer to start working on back porting the babble recover implementation in their v2.6.33 kernel now.

0 Bin Liu over 6 years ago in reply to Bin Liu

TI__Guru*** 125136 points

Tony,

Please apply the following two kernel patches to the Processor SDK v4.0.0.4 kernel. The babble recovery should work on omapl1 now.

0001-usb-musb-Check-for-host-mode-using-is_host_active-on.patch.txt

From 445ef61543da3db5b699f87fb0aa4f227165f6ed Mon Sep 17 00:00:00 2001
From: Jonathan Liu <net147@gmail.com>
Date: Mon, 9 Oct 2017 22:46:12 -0500
Subject: [PATCH] usb: musb: Check for host-mode using is_host_active() on
 reset interrupt

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect IRQ. When this
happens the musb controller switches from host mode to device mode
(it clears MUSB_DEVCTL_HM/MUSB_DEVCTL_SESSION and sets
MUSB_DEVCTL_BDEVICE) and gets stuck in this state.

The babble error is misdetected as a bus reset because MUSB_DEVCTL_HM
was cleared.

To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
to detect babble error so that sunxi musb babble recovery can handle it
by restoring the mode. This information is provided by the driver logic
and does not rely on register contents.

Cc: stable@vger.kernel.org # v4.1+
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/usb/musb/musb_core.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 1ced3af75b05..ff5a1a8989d5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -906,7 +906,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
 	 */
 	if (int_usb & MUSB_INTR_RESET) {
 		handled = IRQ_HANDLED;
-		if (devctl & MUSB_DEVCTL_HM) {
+		if (is_host_active(musb)) {
 			/*
 			 * When BABBLE happens what we can depends on which
 			 * platform MUSB is running, because some platforms
@@ -916,9 +916,7 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
 			 * drop the session.
 			 */
 			dev_err(musb->controller, "Babble\n");
-
-			if (is_host_active(musb))
-				musb_recover_from_babble(musb);
+			musb_recover_from_babble(musb);
 		} else {
 			musb_dbg(musb, "BUS RESET as %s",
 				usb_otg_state_string(musb->xceiv->otg->state));
-- 
1.9.1

0001-usb-musb-da8xx-fix-babble-condition-handling.patch.txt

From 0a461b9e419c4fd4b9fe580746cc5be341dc13ea Mon Sep 17 00:00:00 2001
From: Bin Liu <b-liu@ti.com>
Date: Thu, 2 Nov 2017 10:26:34 -0500
Subject: [PATCH] usb: musb: da8xx: fix babble condition handling

When babble condition happens, the musb controller might automatically
turns off VBUS. On DA8xx platform, the controller generates drvvbus
interrupt for turning off VBUS along with the babble interrupt.

In this case, we should handle the babble interrupt first and recover
from the babble condition.

This change ignores the drvvbus interrupt if babble interrupt is also
generated at the same time, so the babble recovery routine works
properly.

Cc: stable@vger.kernel.org # v3.16+
Signed-off-by: Bin Liu <b-liu@ti.com>
---
 drivers/usb/musb/da8xx.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index df88123274ca..92ed39b63fc2 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -305,7 +305,15 @@ static irqreturn_t da8xx_musb_interrupt(int irq, void *hci)
 			musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
 			portstate(musb->port1_status |= USB_PORT_STAT_POWER);
 			del_timer(&otg_workaround);
-		} else {
+		} else if (!(musb->int_usb & MUSB_INTR_BABBLE)) {
+			/*
+			 * When babble condition happens, drvvbus interrupt
+			 * is also generated. Ignore this drvvbus interrupt
+			 * and let babble interrupt handler recovers the
+			 * controller; otherwise, the host-mode flag is lost
+			 * due to the MUSB_DEV_MODE() call below and babble
+			 * recovery logic will not be called.
+			 */
 			musb->is_active = 0;
 			MUSB_DEV_MODE(musb);
 			otg->default_a = 0;
-- 
1.9.1

Processors

Processors forum

AM1808: USB0_DRVVBUSn drive to LOW sometimes