2010-01-12 09:14:31     USB OTG Problems

Document created by Aaronwu Employee on Aug 20, 2013
Version 1Show Document
  • View in full screen mode

2010-01-12 09:14:31     USB OTG Problems

John Rees (UNITED KINGDOM)

Message: 84465   

 

Hi 

 

I am using the 2009R1 RC6 kernel, bf527 and custom hardware.  I have enabled USB OTG,

which appears to be working fine, I can mount a flash drive and access the data ok.

The problem I have is that there is some strange behaviour detecting A and B cables

and switching to and from OTG host mode.

 

If when the kernel boots and there is no cables attached to the OTG port, then I see

that the musb driver sets the vrsel to inactive, this is done once a second.  Occasionally

I see the vrsel being set to active, even though there is no A type cable attached, this

happens at somewhat random intervals.  When the vrsel is set to active I then get the error:

 

VBUS_ERROR in a_wait_bcon (99, VALID), retry #1, port1 00000100.

 

After the error, vrsel is then set back to in-active.

 

I have put some debug in the musb driver to indicate the state of vrsel, my debug output is

as follows, as well as vrsel state it also prints the MUSB_DEVCTL state:

 

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->1, 1

VBUS_ERROR in a_wait_bcon (99, VALID), retry #1, port1 00000100

vrsel->0, 99

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->1, 1

VBUS_ERROR in a_wait_bcon (99, VALID), retry #2, port1 00000100

vrsel->0, 99

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->0, 81

vrsel->1, 1

VBUS_ERROR in a_wait_bcon (99, VALID), retry #3, port1 00000100

vrsel->0, 99

vrsel->0, 81

vrsel->0, 81

 

 

After 3 VBUS_ERRORS the interface will not work correctly, prior to 3 errors I can insert and

remove a Memory stick which will be detected, after 3 VBUS_ERRORS when a stick is inserted I

get errors of the following:

 

usb 1-1: new high speed USB device using musb_hdrc and address 5

usb 1-1: device not accepting address 5, error -19

hub 1-0:1.0: unable to enumerate USB device on port 1

 

Also I don't see how the the vbuserr_retry variable (musb_core.c)is reset on successful connection, so if

for example plugging and un-plugging a device caused some VBUS_ERRORS, but then connected successful

and you repeated the cycle of un-plugging and plugging, eventuall the the VBUSERR_RETRY_COUNT will

be exceeded and never reset, resulting in the errors above.

 

As a test I upped the VBUSERR_RETRY_COUNT to 10 from 3 and also made the count reset when the

connection is successful, this improved the plugging and un-plugging, but does not solve the original

issue above.

 

If I reboot with the A type cable inserted in the OTG port, then the kernel immediately

activates vrsel and the port appears to operate correctly when a USB memory stick is inserted.

 

Removing the A type cable in this mode however does not appear to disable vrsel, I am not

sure if this should happen or not but if it is the bus power control then it would make

sense that it should disabled when you remove an A type cable as it should go to B mode.

 

So my questions are,

 

1.) Should the OTG interface activate the vrsel at regular intervals, even though no A type device is attached?

2.) Should removal of an A type device disable vrsel?

3.) Should the vbuserr_retry counter be reset on success? Or is there another way to recover the driver?

4.) Has anyone had similar issues?

 

Thanks

 

John Rees

QuoteReplyEditDelete

 

 

2010-01-13 02:09:12     Re: USB OTG Problems

Cliff Cai (CHINA)

Message: 84498   

 

John,

 

1.VBUS is turned off if no A-type device is inserted as your test shows.

 

2.If the VBUS is turned off then no connection will be detected(connection interrupt won't occur) next time an A-plug is inserted in.Also if musb is intended to be used as a host then it should not go to B mode even if A-type device is removed.

 

3.I didn't see your problem on my BF527-EZKIT,but I guess resetting the vbuserr_retry would help to recover from vbus errors.

 

BTW,the callback function of the timer is used to sample the ID pin,so that musb can decide if an A-type device has been inserted.I guess the problem shoudn't have happened except that there is some hardware circuit bug on the custom board.

 

Cliff

QuoteReplyEditDelete

 

 

2010-01-13 02:28:02     Re: USB OTG Problems

Cliff Cai (CHINA)

Message: 84500   

 

one more thing,in latest musb driver(2.6.32),if musb is not in OTG mode, it won't call "musb_platform_try_idle" when device is removed.that function just activates the timer again.

 

see code snippet as follows in /musb_core.c/musb_stage2_irq()

 

if ((int_usb & MUSB_INTR_DISCONNECT) && !musb->ignore_disconnect) {......

 

switch (musb->xceiv->state) {

 

#ifdef CONFIG_USB_MUSB_HDRC_HCD

 

case OTG_STATE_A_HOST:

 

case OTG_STATE_A_SUSPEND:

 

......

 

if (musb->a_wait_bcon != 0 && is_otg_enabled(musb))

 

musb_platform_try_idle(musb, jiffies

 

+ msecs_to_jiffies(musb->a_wait_bcon));

 

break;

 

#endif /* HOST */

 

......

QuoteReplyEditDelete

 

 

2010-01-13 05:16:35     Re: USB OTG Problems

John Rees (UNITED KINGDOM)

Message: 84531   

 

Hi Cliff,

 

Thankyou for you comments, I will look further into possible hardware problems and A/B detection a little more and post my findings.

 

Thanks

 

John

QuoteReplyEditDelete

 

 

2010-01-14 10:30:05     Re: USB OTG Problems

John Rees (UNITED KINGDOM)

Message: 84581   

 

Hi,

 

After some investigation some of the instabilities I see, they appear to come from reading the MUSB_DEVCTL too early after starting a session.

 

I am not 100% sure about my fix, but in the bf527 HRM page 26-116 it shows a register called USB_LINKINFO, there is not much documentation on this but reading the info on the WTID field, led me to believe that the ID input is not vaid for a period of time specified by WTID.  As far as I can determine the ID is not sampled until a session is initiated. I read this as you should delay reading the ID state in MUSB_DEVCTL after starting a session for at least the time specified by the WTID value.

 

Can you/anyone confirm if this is the case?

 

I changed the code so that the musb_conn_timer_handler is called every 100ms and after starting a session the ID is not read for a further 100ms.  This appears to fix my problems.

 

Thanks

 

John

QuoteReplyEditDelete

 

 

2010-01-14 13:03:45     Re: USB OTG Problems

Robin Getz (UNITED STATES)

Message: 84583   

 

John:

 

Can you post a patch so we can take an exact look at what you are doing?

 

Thanks

 

-Robin

QuoteReplyEditDelete

 

 

2010-01-18 09:47:08     Re: USB OTG Problems

John Rees (UNITED KINGDOM)

Message: 84717   

 

Hi Robin

 

I have attached my modified files for my USB OTG changes.

 

I have made the polarity of turning on vrsel configurable as some of our boards are active low and others active high.  So my musb_config in the board directory is of the following:

 

 

#define VRSEL_ACTIVE 0

 

static struct musb_hdrc_config musb_config = {

.multipoint = 0,

.dyn_fifo = 0,

.soft_con = 1,

.dma = 1,

.num_eps = 8,

.dma_channels = 8,

.gpio_vrsel = GPIO_PG13,

.gpio_vrsel_active = VRSEL_ACTIVE,

.gpio_vrsel_inactive = (!VRSEL_ACTIVE),

};

 

The changes I have made to OTG, I would not recommend using as is, it was merely an attempt to prove I can fix the problem I was having, it would be better if the changes were built more elegently into the USB OTG state machine, all I need at the moment was to prove that our hardware was functioning.

 

Also in blackfin.c, the USB_PLLOSC_CTRL should be set to 0x30a8 for the ezkit board.  In the files below they are custom settings for our board.

 

Thanks

 

John

 

musb.h

blackfin.h

blackfin.c

musb_core.c

musb_core.h

QuoteReplyEditDelete

 

 

2010-01-18 10:04:56     Re: USB OTG Problems

Robin Getz (UNITED STATES)

Message: 84719   

 

John:

 

Thanks.

 

Someone will have a look, and try to get this into the platform file properly.

 

-Robin

Outcomes