USB DRVVBUS pin on DM355

Hi,

I am not exactly sure of everything you are trying to communicate with us and you probably need to give more details if my response seems not to address your issue.

When you say that you want the USB_DRVVBUS to work again not sure by what you means. I suspect that you have disabled the Voltage on the VBUS line. Please use a Digital Multi Meter and check the voltage on the VBUS line.

There are other ways you can conserve the power by killing the Session, i.e., Clearing DEVCTL.SESSION. That way, you keep USB_DRVVBUS assigned for the USB use and let the Controller turn it on an off as needed.

The other way is to use GPIO to control the external power source. But in this case, you have to synchronize your s/w with the h/w state.

Have you received a VBUS Error Interrupt? What I suspect has happened is that by the time the USB Controller attempts to turn on the external Power Supply and this pin was not assigned for it and a short time later when it observes that there is no voltage on the VBUS line, it has shut down. You attempted to relinquish back the signal after the shut down event has been exercised.

So, you can try by assigning USB_DRVVBUS pin prior to starting the USB task and see what happens.

Best regards, Zegeye

Thank you Zegeye,

You're are right, I did not give a lot of details. If I'm honest, I don't really know what's wrong!!!

Software wise, I have gone back to the 'out of the box' uImage in .../dvsdk_1_30_00_41/PSP_XX_XX_XX_XX/bin

Does the USB controller have any non-volatile registers!!!

Is there anything on the DM355EVM Hardware that I should check? All I know is that the USB_DRVVBUS is driven low, when in normal mode...

I must confess, at the moment, I have no idea how to get the USB port to work again...

Thanks again...

Amjad.

Hi,

No Pb.

So long as you do not kill the clock, the core registers content should all be in tact. Some of the core register contents are also affected by bus conditions, like RESET.

Having said that, your solution is operating as a Host, i.e. you are connecting to flash drives, you will have to be the one sourcing the voltage on the VBUS and USB_DRVVBUS is used to control the external power supply on the board.

The EVM has a 5V Power Supply that sources power to the VBUS line when the USB_DRVVBUS is driven high. This signal is driven high when this signal is assigned to be used by the USB and also when the USB is assuming the role of a Host. What you have to do is ensure that the PINUMX configuration is programmed properly that the USB_DRVVBUS is assigned to be used by the USB Controller. In order for the USB to assume the role of a Host, you will need to insure that the A-End of the USB cable is connected to the EVM. If not using a miniA/B connector, and you are using a standard TypeA connector, you need to insure that the USB_ID pin is grounded so that the USB core assumes the role of a Host.

If the above is in place, then when you start a Session, the USB Controller will assume a role of a Host followed by driving the USB_DRVVBUS to turn on the external P/S to source the 5V power. Then it will check if the 5V voltage is present on the VBUS line (actually has to be >= 4.4V). If this is the case it proceeds on detecting a Device presence on the Bus.

When the USB Controller assumes the role of a Host, it will enable its internal pull-downs 15K Ohms on both D+ and D- lines and uses the state of these data lines to determine if a Device is present. If a Flash Drive you are attempting to connect is present, it will pull one of the data lines (most likely the D+ line since it is either a FS or HS device) when the Device sees a Voltage on the VBUS line. When the Host sees a device present, it will invoke a RESET bus condition. Then after the enumeration process is continued.

In summary, if the USB_DRVVBUS is not driven high, the 5V on the VBUS line will never be sourced. If this power is not present, not only the Device will fail to pull the D+ line high, but also the controller will abort since by generating VBUS error since it's unable to generate the required power.

May be, in this case it might be more benefiicial to address this issue over the phone if you need more details. Post your # and I will call you.

Best regards, Zegeye

Hi Zegeye,

My immediate thought is that as far as I know all the USB IF signal are dedicated USB signals, therefore, Pinmux'ing shouldn't be an issue...

Other than that, the key question for me, is still, is there any state held by the USB controller AFTER a power cycle?

Once again, thanks for your help, my phone number +44 1443 812 777.

hello again,

Thank you for the phone call yesterday.

After a bit of Hardware debugging, we have found out something quite worrying.

We measured the impedence on the USB_ID pin. We found that on the working board the impdence measured around 10Kohms. On the failing board, it around 40ohms.

Am I right in thinking that this implies that the USB_ID is damaged internally, somehow?

Hi,

It seems that the device is damaged. The expected impedence on the ID pin is greater than 10K Ohms. Need to replace it.

All devices will differ with their values due to different processes. Even within the same process they will differ, but very slightly. It is expected to see difference accross devices but all values have to be greater than 10K Ohms.

Best regards, Zegeye

Hi Zegeye,

Yes, I agree this should now be one thread. At that time i wasn't sure if the drvvbus or usb_id pin was the problem. I guess I can now safely say it is the USB_ID.

I have an idea. Can I, using TESTMODE.FORCE_HOST,  'trick' the USB controller into acting like a HOST despite the USB_ID pin being dead??

I have tried it, but get a lot of BABBLE_ERROR interrupts.

Is this idea worth pursuing?

Thanks.

Hi Amjad,

Thanks.

Well, TESTMODE is only present for debug purposes, mostly PHY related issues. I am not sure if you can do anything useful with this. I have not done much on this.

TESTMODE is supposed to work without even connecting to a peripheral. The babble interrupt is not a good thing. The controller is supposed to end the session when receiving this interrupt.

I think the damage is not just the USB_ID pin. May be something other than the USB_ID pin is damaged and its symptom is also showning on the ID pin.

It might be intersting to see how the good device behaves in TESTMODE.

My advise to you is to replace the DSP.

Best regards, Zegeye

Pl. pay attention to the data polarity routing on your board.  On DM355 EVM it was inverted and hence the code is setup for that config in the driver.  In your design if the data lines are not reversed (which probably is the case) pl. update the davinci.c phy config accordingly for your board.

regards

swami

Hi Swami,

Thank you for your suggestion. I should add that this is on the DM355 Eval Board!

We haven't changed the hardware.

Hi all,

I just encountered a similar problem on the linux otg drivers.

When i use the board,the usb host could work normal,just like use a udisk. But the otg interface could not find the device.

I just do this,use the udisk which work narmal on the usb host,insert the otg,no current measurement with a multimeter.

I find the usb_drvvbus control the power,but i don't know how to use the drvvbus in the kernel 2.6.32-rc5.

I use the net in order to improve the problem.It have passed a week.But haven't a result.

Who can give me some advice?

The board use the processor am3517.

Thanks!