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

John Rees (UNITED KINGDOM)

Message: 84465

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->1, 1

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

vrsel->0, 99

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->1, 1

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

vrsel->0, 99

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