USB driver issue ? --- WEC7 BSP

I beleive this is correct operation for OTG as if you read the OTG spec the VBUS line is "pulsed" as normal operation until it can determine operation mode.

If you look under the USB directory in the drivers folder you will usually see something like:

USBCDMA

USBFN

USBH

USBOTG

These are the host (USBH), client (USBFN) and OTG (USBOTG) overlay components. It is possible to just include the HOST only component but is usually not a selectable catalog component. They usually just have the OTG as the selectable component but if you look closer you will see it pulls in all the sub components (USBFN,USBH,USBOTG etc). You can include just the host component by defining BSP_USBH1 (for example) as an enviroment variable. There are probably other ways to include just the host component.

Dear David-san,

Thank you for your quick reply.

I understood the behavior of the OTG driver is normal action. Also I don't know why ID pin is not effective to OTG driver.

But, fortunately, my customer would like to fix the driver as the host mode.

You said me as the following. 

It is possible to just include the HOST only component but is usually not a selectable catalog component. They usually just have the OTG as the selectable component but if you look closer you will see it pulls in all the sub components (USBFN,USBH,USBOTG etc). You can include just the host component by defining BSP_USBH1 (for example) as an enviroment variable. There are probably other ways to include just the host component.

One of solution that you said is to use an environment variable. But I don't know how to do it.  Please let me know  how to fix the host mode.

I appreciate your quick reply.

Best regards,

Michi

Dear David-san,

I would like to know regarding OTG driver behavior.

Customer's system has one issue. When customer's system boots up with USB memory insertion to USB connector, USB interrupts occurs two times.

And USB module fails to recognize USB memory.

But, USB interrupt occurs one time when USB memory is inserted after system booted up. And USB module succeeds to recognize USB memory in this

situation. Is this action(interrupts two times)  normal as OTG driver?

For this issue, my customer's workaround is the below.

USB driver is stopped once after booted up, and USB driver is started again after the first interrupt occurred. Its timing is before second interrupt occurring.

My customer succeeded to recognize USB memory insertion  by the above workaround.

Is this workaround correct action?

Please let me know.

Best regards,

Michi

Hi,

We have not been solved this issue.

Could anyone support us for this　issue？

Best regards,

Michi

Dear Michi-san,

What I could understand from the problem description is that the USB interrupt is occurring two times in the beginning. 

The USB controller architecture of AM3874 has a hardware wrapper interface which acts as a wrapper layer to the USB OTG controller. Interrupts can be routed from OTG controller as well as the wrapper interface. The same interrupt can trigger simultaneously. Basically one of them needs to be disabled to avoid this behavior. I'm not 100% sure, but most likely this can be the reason for the behavior that you are seeing.

Dear Renjith-san,

Thank you for your reply.

But I don't understand your description well.

Does one of two interrupts come from USB OTG controller? Other one come from Wrapper layer?

Why does AM3874 has a hardware wrapper? If AM3874 host mode receives an insertion interrupt,

does AM3874 release the host mode?

I am sorry I don't know USB OTG action. Please advise me again.

Best regards,

Michi

For disabled the switch level USB_VBUS in host mode need to remove a variable BSP_USBOTG1 from a file pbcxml (e. g. file path D:\WINCE700\platform\AM387X_BSP\CATALOG\am387x_bsp.pbcxml)

  <Item Id="AM387x:TI:MUSB">
    <Title>MUSB OTG driver</Title>
    <Description>MUSB OTG Driver for the AM387X EVM</Description>
    <Type>BspSpecific</Type>
    <SysgenVariable>SYSGEN_USB</SysgenVariable>
    <Variable>BSP_USBOTG0</Variable>
    <Variable>BSP_USBFN0</Variable>
    <Variable>BSP_USBOTG1</Variable>
    <Variable>BSP_USBH1</Variable>
    <Module>am387x_usbfn.dll</Module>
    <Module>am387x_usbh.dll</Module>
    <Module>am387x_usbotg.dll</Module>
    <Location>Drivers\</Location>
  </Item>

Dear Michi-san,

Sorry for my delayed response. We can discuss this over an email. Hope this is fine with you.

Dear Denis-san,

Thank you for your cooperation.

Our customer tried to modify the BSP source code based on your advice.

However, the symptom was not improved in their system.  Did you confirm this solution in TI EVM?

I appreciate your support.

Best regards,

Michi

Hi guys!
for resolve this problem:

"When AM3874 system boots up with inserted USB memory, its USB memory is not recognized. When the USB memory is connected after the AM3874 system booted up, USB memory is recognized ceratinly. " 

Try my fixed HOST driver 

1727.chw.cpp

Replace the file chw.cpp in the folder d:\WINCE700\platform\common\src\soc\COMMON_TI_V1\AM387X\USB\USBH\chw.cpp 

Dear Denis-san,

Thank you for your information.

I have one quetion.

My customer tried to use the previos host driver. And it was unstable.

How about your modified driver? Is it stable?

And if possible, please let me know what you did for fixing driver.

Best regards,

Michi

just compare file with original file.
And see in datasheet 25.6.2 Babble Event Detection as a USB Host

Dear Denis-san,

Thank you for you quick reply.

If possible, I would like to talk with you by email. Is it possible?

Best regards,

Michi