• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 35 subscribers
  • Views 3847 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RM48 USB Host Driver

Griswald Brooks
Intellectual 460 points
Other Parts Discussed in Thread: RM48L950, HALCOGEN, OMAP5912, OMAPL138

Hello,

We've been working on trying to get a USB Host driver going on the RM48L950 with little progress. The demo code that comes with the Hercules Safety MCU demo allows us to loopback but doesn't seem to be easily expandable to a driver that can enumerate other devices.

Is it possible that someone could send/post a USB Host Driver for the RM48 that would allow us to enumerate new devices?

To be clear, we're not looking for a complete implementation that will support mouse, keyboard, etc, but just something that will allow us to do basic enumeration and develop off of.

Also, Host Drivers are not the same as Device Drivers. In other words this page: http://processors.wiki.ti.com/index.php/HALCoGen_USB_Device_-_driver_%26_CDC_Class is not helpful since it discusses how to get the USB Device side working on the RM48, which is its own animal.

Regards,

Griswald Brooks

  • 0
    TI__Intellectual 2310 points

    Hi Griswald,

    I am checking with our team here and I will let you know as soon as possible.

    Regards

    Abhishek

     

  • 0
    TI__Prodigy 450 points

    Griswald,

    The USBH on RM48 is based on open standard OHCI v1.0a and is compatible with USB2.0. So you can refer to any OHCI USBH Driver (eg., Linux implementation) for a sample code to enumerate the devices. Regarding the RM48 device specifics like Clocking & Pinmux you can use the HALCoGen tool to configure.

    Regards,
    Pramod

  • 0 in reply to Pramod Bhardwaj
    Intellectual 460 points

    Pramod,

    We had been looking at libusb for example, but where that falls short is when the linux driver accesses the hardware, it uses the linux syscalls, which obfuscate actual access to the OHCI side of things. This is actually the missing key to the whole situation. We've been working with the LPC version of the LUFA drivers trying to port that over to the RM48, but progress has been slow. Before that we looked at the Stellaris driver, but that seems to go into some ROM area, which is where things get lost.

    Has a driver for this board not been written?

    Regards,

    Griswald Brooks

  • 0 in reply to Griswald Brooks
    TI__Expert 7650 points

    Griswald,

    I am not aware of a USB Host driver example from TI.  This stack and driver is available from Micrium, however.

  • 0 in reply to Brian Fortman
    Intellectual 460 points

    Brian,

    The Micrium solution is quite expensive.

    Regards,

    Griswald Brooks

  • 0 in reply to Griswald Brooks
    Intellectual 745 points

    Hi Griswald,

    You can look on NXPs LPCopen library  there they have an OHCI driver for their usb solution. If you use it as a starting point it would reduce your effort.  One thing you have to set aside is the host controller clocking which is almost missed in the ref manual.  It should be clocked at 48MHz.

    Regards, Dmitri.  

  • 0 in reply to Dmitri Snejko
    Intellectual 615 points

    Hi Griswald,

    Were you able to complete and run USBH for RM48?

    Thanks,
    Jam

  • 0 in reply to Jam Akh
    Intellectual 460 points

    Nope. I never did get it to work.

  • 0 in reply to Griswald Brooks
    Intellectual 615 points

    So Can TI fellows verify that TI has tested USB host either on RM46 or on RM48 or some one else has done it? so that I might know that all is good and I can proceed further.

    Thanks & BR,

    Jumshed

  • 0 in reply to Jam Akh
    TI__Guru 68820 points
    Yes it is tested and we have also used the same IP on many previous devices such as OMAP5912 and OMAPL137.
    We picked this host because it is an industry standard OHCI controller ... which means there is not a lot of 'compromise' in functionality going on like there may be with other 'embedded' controllers. For example some of the OTG controllers only allow a few device endpoints to be addressed at a time without reprogramming the controller [look at the OMAPL137's OTG controller as an example].

    With OHCI your bus topology is really only limited by the amount of RAM available for transfer descriptors, endpoint descriptors, and data buffers. Since you can put an external SDRAM on these devices you could address a really populated USB bus if you wanted to.

    Now when we extensively test it's done at a low level, configuring the IP and setting up descriptors. We have also done some bench testing with Micrium's USB stack but that isn't extensive.

    I think you can have quite a lot of confidence in the hardware specifically because it is has been used on many other silicon and is an industry standard controller model. Same model that was used on many PC's in fact [google USB OHCI].

    But a USB host stack is not a small piece of software. An analogy might be the difference between test cases for an 'ethernet mac' and having an entire TCP/IP stack plus all of the common protocols.

    There is a huge effort and value in the latter - which I think is why you wind up having to pay for a complete solution.

    If all you need to do on the other hand is to send packets/receive to a specific USB device with a few endpoints then there is enough information in the USB OHCI standard including example data structures and notes on implementation that will get you over this hump with some work. But it would not be the kind of solution where you could just plug in a USB thumb drive and start accessing files & directories off of it.
  • 0 in reply to Anthony F. Seely
    Intellectual 615 points

    Hi Anthony F. Seely,

    Thanks for detail reply. I know OHCI is a standard, I have already implemented and run it on Omapl138 and some other platforms also  and it is working fine. I am facing problem in porting it for RM46 Hercules development kit, that's why I asked the question whether TI has tested it for RM46 Hercules development kit.

    As OHCI and USB part is same for both Omapl138 and RM46. The only additional, I need to do is Pin muxing (configured 10 pins) and Clock enabling(VCLK3=VCLkA3_DIVR =48MHz and VCLKA3_DIVR/4=12MHz) for RM46 and I am doing that, but I receive the error even in 1st Transfer descriptor that device is not responding (CC=5). Can you people help me, is there any other additional initialization things that needs to be done for RM46/RM48 USBHost. I have also configured switch S2 for USBH.

    Best Regards,

    Jam

  • 0 in reply to Jam Akh
    TI__Guru 68820 points

    Hi Jam,


    One thing that is different on the RM46 versus the OMAPL138 is that on the L138 the port power control was handled 'outside' the OHCI controller.

    On the RM46 we cleaned this up - so the port power control is now not done through external GIO registers but done through the OHCI controller's root hub port status/control registers - completely contained within the OHCI controller.

    Did you make a change to your code to account for this?   If not then maybe it's an issue of not having the power switch turned on.

    Another way to check is just to see if your USB device is getting +5V on VBUS.    There should be an external power switch on the HDK it's not hard-wired.

  • 0 in reply to Anthony F. Seely
    Intellectual 615 points
    Thanks, I was able to run it successfully. Will share more detail later on.
    BR,
    Jam