This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP 3530 USB host bulk read problem

We are using OMAP 3530 USB host with the USB3320 as the transceiver on our custom board. We are facing some problems in Bulk read, earlier we saw that from pen drive if we try to read a file(more than 10MB) it was hanging in-between but copying to pen drive was not a problem. Now we have a custom USB device which is connected to the usb host and even this uses bulk transfer, so when we try to read from the device we will be able to read for a while and then it is failing. We are unable to figure out what is the problem whether the transceiver initialization, host driver or the OMAP usb host controller. I read that LogicPD says OMAP USB host is having some problem so bulk read is pushing the host to get locked. Can anyone please comment on this?

  • I assume you are using Linux as the OS platform.  If so can you provide me the version information of the kernel or the LSP information?

    Can you reproduce the issue on TI EVM?  This will help us to understand were the issue could be.  We have tested it on TI EVM platforms and have not seen the issue you have mentioned.

    Is there any other USB activity occuring when say read/write to the USB HDD is in progress?

    regards

    swami

  • This is a system level issue that is being encountered on a lot of boards and is being investigated. Feel free to contact me direct for a detailed explanation on a possible fix.

    Gerald

  • Thanks for the reply...

    Sorry i dint mention the OS, we are using WinCE 6.0 on LogicPD board. We are not having the TI EVM board with us. We have not connected any other device. On the TI EVM i think USB3320(or the USB332x series) transceiver is used so can you please tell us the register initialization for it?

    Gerald: can you please tell how i can contact you?

     

     

  • I see. The issue seems to be a noise issue that appears to be OMAP device specific. It does not show up on all boards. It looks like the USB3320 needs to have it's own 1.8V rail seperated from the OMAP1.8V rail. There has been some success with activating the smart reflex on VDD2, but it does not work on all devices. You might try this and see if it helps in your case.

    My direct email is g-coley1@ti.com

    Gerald

  • Hi Gerald,

    We have used OMAP 3503 CBC package in our design and connected it to the USB3320 from SMSC through OMAP port 2, We are however unable to drive the Clock from OMAP 3503, we are currently using We have the kernel version 2.6.27 from TI mistral EVM, What are steps required to ensure that we have this port enabled.

    Regards
    Rejo

  • You need to make sure that you have the pin mux set correctly and the driver correctly installed. I have never seen this issue anywhere before when using the provided drivers. There could be an issue in the schematic as well where the improper pin is being used. I suggest you look at the EVM schematic. I can only assume that this is the issue as you have stated and that there could be other issues as well such as the reset not being setup properly on the design.

     

    Another suggestion is to look at the Beagle design and make sure there are no differences between it and your design.

     

    Gerald

  • Hi Gerald,

    Do you figure out this issue?

    We are using OMAP 3530 as the mother board CPU and tried to make a connection between OMAP (Host) and Davinci (device) via USB connection...I got similar issues alike the posted above.... Here is details on my problem.

    1) we are using Linux OS and Libusb 1.0.8

    2) if we configure the Davinci endpoint size to be 64 bytes, both Bulk read and Bulk write works perfect.

    3) If we configure Davinci endpoint size to be 512 bytes, bulk write still works fine...but bulk read will have 1 % failure.

    4) By dumping out the OMAP side receiving buffer, I saw data byte missing - somehow the missing byte always locates around offset 408 (512 total).

    5) We use Lecroy USB analyzer to capture the trace, but seeing all data bytes shows correctly on the bus.

    Is this a TI awared issue?

    Thanks, Haifeng