USB memory issue?!

Hi, I have one more questions.

My customer uses Host mode of USB.

They have other own WEC7 system with AM3517. This system can fix USB as Host mode.

But, as you know from the above picture, their AM3874 system can't fix USB as host mode.

Michi Yama said:

When customer's system power-on with USB memory insertion, some USB memory is not recognized by WEC7 OS.

Is the USB drive recognized if it is plugged in after the system powered on?

Michi Yama said:

why VBUS is down to 0V after VBUS went to 5V.  I think this is not necessary sequnce for USB device.

There are multiple things which could cause VBUS droop. How big is the capacitor on VBUS? The USB Specs require minimum 120uF for host mode.

Michi Yama said:

So I tested same thing on TI's EVM. My customer uses AM3874 processor. As my result, I had confirmed the same sequence as the above.

Have you placed a jumper on J26? It will place the 150uF cap on VBUS, which is required for host mode.

Michi Yama said:

TI's EVM(TI 814x) can be used only USB1 channel. USB0 channel is NG. 

Hmm, I have not used my 814x evm for years, but I thought its USB0 port worked...

Anyway, from all your description, I suspect the custom board does not have enough cap on VBUS, and adding a >120uF cap should fix it. Please let me know if this is the case.

To make it simple, for device mode, the USBx_MODE register should be 0x180; for host mode, it should be 0x80.

Its bit7 should be always 1, otherwise, bit8 is ignored. Please refer to TRM (rev I) section 16.5.2.35 for details.

Michi Yama said:

When the above code is executed,  IDDIG bit is cleared, as you know.

This code should never be executed for host-only mode.

If the customer only need host-only mode, they should ensure the driver to bypass the otg logic, and never clear the IDDIG bit. Otherwise, it is very easy to run into all different weird cases.

I cannot tell what exactly to do in WINCE driver, since I know nothing about WINCE.

Dear Bin-san,

Thank you for your reply.

＞To make it simple, for device mode, the USBx_MODE register should be 0x180; for host mode, it should be 0x80.

I am sorry, my bad. I was referring to TRM rev I for AM335x - http://www.ti.com/litv/pdf/spruh73i. But its Section 16.5..2.35 is applicable to AM387x.

In the previous versions of TRMs for both AM387x and AM335x, Bit7 was marked as reserved.

Bin-san,

Thank you for your support.

I confirmed the bit 7 of the USB0MODE Register of AM3874.

According to your advice, bit 7 must be set for Host mode. It means that Bit7 must be changed from reset value.

But I can't change bit7. The reset value of bit7 is "0". And I could not  change bit7.

Is USBx mode register same between AM335x and AM3874?

I am confused. Please check it in your side.

I appreciate your quick reply.

Best regards,

Michi

Michi-san,

I apologize for my misleading information above - I thought bit7,8 of USB0MODE on AM387x should work in the same way as that on AM335x, since both devices use the same USB h/w module, but after talked with the Design team, it turned out that the bit7,8 of USB0MODE are not used on AM387x at all.

So the WinCE driver you mentioned above which does 'MODE_R &= ‾0x080' has no any effect at all, you can ignore it.

Have you checked the cap on VBUS? Can you please answer my questions in my first response? That probably gives me a direction to debug the issue.

Bin-san,

Thank you for your support.

I asked to my customer about the cap on VBUS. At present, they use 100uF capacitor. So I requested them to change the capacitance to minimum 120uF, and check the VBUS action. I will report its result as soon as I will get it.

By the way, I would like to reconfirm.

If customer would like to use USB as host mode, customer should clear Bit 8 (=0) of USBx mode register. Is this enough condition for host mode? Are there any register setting?

I appreciate your quick reply.

Best regards,

Michi

Michi Yama said:

If customer would like to use USB as host mode, customer should clear Bit 8 (=0) of USBx mode register. Is this enough condition for host mode? Are there any register setting?

Bit8 of USBxMODE is not hooked up in the silicon, so changing its value has no effect to the USB functionality.

I believe in general the sw and hw are correct in the customer's system, since some USB devices work without issues.

After replaced the cap, if the issue still happens, can you please ask the customer to add a debug message in the MUSB ISR to print the value of USB0IRQSTAT1 register (offset 0x1034) in the USB0_CTRL region (AM387x TRM Section 25.9.2.1.9). Please check if its bit7 (VBUS valid) ever set while the problematic USB device is plugged in.

Dear Bin-san,

Thank you for your cooperation.

My customer would like to know the reason of changing the capacitor 100uF to 120uF. They does not agree to change the capacitor  by only reason it is out of USB specification.  What effect is expected by changing the capacitor? Could you explain it to me?

Best regards,

Michi

Dear Bin-san,

Thank you for your cooperation.

I hav one more question.

> Bit8 of USBxMODE is not hooked up in the silicon, so changing its value has no effect to the USB functionality.

If Bit 8 of USBx Mode register is invalid, how does customer set USB mode by software?

Please let me know.

Best regards,

Michi

Michi Yama said:

My customer would like to know the reason of changing the capacitor 100uF to 120uF. They does not agree to change the capacitor  by only reason it is out of USB specification.

Most of the cases (>90%?) I see which has the same symptom as this one are due to insufficient VBUS cap. Increasing the cap is the first step to investigate the issue. If your customer does not want to follow my recommendations, then I cannot help on their issues. We don't support the systems/configurations which are out of the Specs.

BTY, the Specs exist for reasons.

Michi Yama said:

If Bit 8 of USBx Mode register is invalid, how does customer set USB mode by software?

In practice, The USBx_ID pin is used for switching between host and device mode. You should not use USBxMODE register. The TRM USB chapter has details about how the MUSB controller works.

As Bin stated above, this devices does not have the register that allows the ID pin value to be forced by software.

The ID pin must be connected to ground for the MUSB controller to know it should operate in host mode.

Have they connected the respective ID pin to ground?

Based on the VBUS waveform provided in the first post, the attached memory device does not appear to be causing excessive voltage droop on VBUS as a result of the customer using 100uF rather than the 120uF minimum specified by the USB specification.  However, this may not be true for all USB peripherals.  Bin was suggesting they change the capacitor to be compliant with the USB specification.  Otherwise, they may have compatibility issues with some USB peripherals.

Regards,
Paul

Bin san Paul-san,

Thank you for your support.

Our customer tested to change the capacitor value from 100 uF to 220uF.

Unfortunately, customer could not get the effect for changing.

Please see the below picture.

Also, customer connecetd ID pin to ground.  This shows MUSB controller operates in host mode, doesn't this?

In next step, What should my customer check? 

Best regards,

Michi 

Yama-san,

Bin Liu said:

After replaced the cap, if the issue still happens, can you please ask the customer to add a debug message in the MUSB ISR to print the value of USB0IRQSTAT1 register (offset 0x1034) in the USB0_CTRL region (AM387x TRM Section 25.9.2.1.9). Please check if its bit7 (VBUS valid) ever set while the problematic USB device is plugged in.

Has your customer checked the Interrupt register?

A few more questions:

1. Who is driving USB0_DRVVBUS pin in this design? Could you please share the USB portion of the Schematics?

2. In your first post, you mentioned that the issue happens when the USB device plugged in the USB port before powering on the board. Does the issue also happen when plug in the device _after_the board booted up?

3. You also mentioned the scope waveform is the same on the EVM with WinCE. Can you please download the Linux SDK for the EVM from ti.com and test the usb device to see if the issue still happens on the EVM with Linux?

When testing on the EVM usb0 port, make sure you have jumpers on J22 & J25.

Dear Bin-san,

Thank you for your continuous support.

Regarding your questions, please see the below.

> 1. Who is driving USB0_DRVVBUS pin in this design? Could you please share the USB portion of the >Schematics?

-> I think it is same as AM3874EVM. It is USB module of AM3874. Unfortunately, my customer never disclose the schematics.

> 2. In your first post, you mentioned that the issue happens when the USB device plugged in the USB port before > powering on the board. Does the issue also happen when plug in the device _after_the board booted up?

-> No, this issue happens only when USB device plugged in the USB port before powering on the board.

> 3. You also mentioned the scope waveform is the same on the EVM with WinCE. Can you please download the >Linux SDK for the EVM from ti.com and test the usb device to see if the issue still happens on the EVM with  >Linux?

-> I will try it. But I may need some time for doing it.

Best regards,

Michi 

Dear Bin-san,

Thank you for your support.

> When testing on the EVM usb0 port, make sure you have jumpers on J22 & J25.

Regarding your question, I believe the jumper setting is no problem when I tested the EVM with WEC7.

Best regards,

Michi

Michi Yama said:

-> I think it is same as AM3874EVM. It is USB module of AM3874.

Could you please double check this with the customer? And is it possible to get the USB portion of the SCH?

I will wait for your test result on EVM with Linux.

Yama-san,

Could you please ask the customer to try one thing on software? I am not familiar with WinCE, but I believe during the MUSB driver initialization, at one point the driver will set DEVCTL[bit0] (which is the SESSION bit) to let the controller transition to host mode. The test is to add a delay (maybe a few sec delay) when setting the SESSION bit, which will delay the device enumeration.

Please also ask the customer to print the Interrupt register when the issue happens as I asked before. This is important info for debugging the issue.

Bin-san,

Thank you for your support.

I would like to reconfirm one thing.

You said as the following the before.

>I thought bit7,8 of USB0MODE on AM387x should work in the same way as that on AM335x, since both devices >use the same USB h/w module, but after talked with the Design team, it turned out that the bit7,8 of USB0MODE >are not used on AM387x at all.

>So the WinCE driver you mentioned above which does 'MODE_R &= ‾0x080' has no any effect at all, you can >ignore it.

According to my test, IDDIG bit (bit 8 of USB0MODE register) is effective.

IDDIG bit  =0  and ID pin =Low --------- USB module is fixed as Host.

IDDIG bit =1   and ID pin=Low ---------- USB module is not fixed. It is changed Host and Device ( It is rolled.)

7bit (reserved)  -----  It is no effect.

Is IDDIG bit really ignored?

Please let me know.

Best regards,

Michi

Michi Yama said:

According to my test, IDDIG bit (bit 8 of USB0MODE register) is effective.

IDDIG bit  =0  and ID pin =Low --------- USB module is fixed as Host.

IDDIG bit =1   and ID pin=Low ---------- USB module is not fixed. It is changed Host and Device ( It is rolled.)

I am unable to reproduce this on am387 evm with Linux ezsdk.

I set IDDIG bit to 1, added jumper J23 (which grounds USB1 ID pin), set SESSION bit on the USB1_DEVCTL register, then the USB1_DEVCTL stays at 0x19, which means USB1 is fixed in the host mode.

Jumper 23 was added before power on the board.