Hercules RM48L952ZWT USB Host Controller

Hi Tammy,

1. Memory map is in the device datasheet, SPNS177. Table 4-21 page 73 (in rev B of this doc, rev C might come soon...)
USB OHCI base address is 0xFCF7_8B00

2. No, the OHCI accesses all of the data structures in main memory.

3. Basically. there is a matrix in Table 4-22. It shows (for example) that the OHCI controller can't access the OTP sector and CRC.
But the important memories (RAM, EMIF) are yes.

4. Other than what is called out in the OHCI spec, no. You'd be limited by how much system memory you allocate to the OHCI data structures.
OHCI doesn't really have a simple 'buffer' model like the pipes on the USB device. Instead the OHCI controller walks (several) linked lists of endpoint descriptor data structures that you put in main memory, based on the enumeration that your controller does. These endpoint descriptors then have a pointer to linked lists of transfer descriptors. And these descriptors point to small chunks of 'payload' buffers if you will. But it's purely a construct in main memory aside from the pointers to the heads of these lists that are kept in the controller hardware.
The OHCI controller is capable of reading and writing memory itself (it includes a bus master, it does not need support from the DMA controller module like the SPI or SCI do...).

Some good google searches on the topic would be OpenHCI and OpenHCD - to get information about the specs and driver model respectively. They have some reference low-level functions that are useful. But this type of software stack is something you may really want to purchase instead of building from scratch.

Hi Thank you. Yes we are using the Mircium (OSII) USBH library as your recommend. We have a structure that needs to be configured according to the TI HW spec:

USBH_HC_CFG USBH_HC_RM48L952Cfg = {
(CPU_ADDR)0xFCF78B00u, /* Base addr of host controller hw registers. */
(CPU_ADDR)0x00000000u, /* Base addr of host controller dedicated mem. */
0u, /* Size of host controller dedicated mem. */
DEF_ENABLED, /* Does HC can access sys mem? */
1024u, /* Data buf max len. */
2u, /* Max nbr opened bulk EP. */
2u, /* Max nbr opened intr EP. */
2u /* Max nbr opened isoc EP. */
};

So 0xFCF78B00u = Base addr of host controller hw registers as you stated above and in the TI manual.

1- Just to double check I understood above, there is no Base address/size of RM48L952 host controller dedicated memory ? We get an error when trying to initialize the HC on the RM48L952 (specifically allocating memory).

2- Are there steps in HalCoGen (aside from PINMUX Host0) that need to be done to allow the driver to initialize the HW?
3. The USB Host physical port on the Hercules board, is that connected to USBHost0 or USBHost1 on Hercules?

Thank you again

Hi Tammy,

I have a folder where I downloaded their example in 2011 and worked with it. There was a file Micrium_RM48_USBH-V3\Micrium\Software\EvalBoards\TI\RM48-ARGOBOARD\IAR\uCOS-III-USBH-V3\usbh_cfg.h and in this file you would
configure the number of resources that would then translate into memory being allocated to store the descriptors and
buffers for these resources. So maybe you need to check this file to make sure it's in sync w. the size of the USB bus
that you are trying to work with. [you need a lot less resources if your use model is to only plug in a thumb drive, compared to say a hub and multiple devices... each device you plug in needs endpoint descriptors, transfer descriptors, and some buffer space].

The example folder I have also had 0x0000000 for the dedicated mem. Makes sense since we don't have any and we have 'Does HC can access sys mem?' set to enabled. There are some controllers with memory built in, particularly on MCUs where OTG is popular and the embedded memory does double duty in host mode -- but these can be really limiting because once you run out of the embedded memory you can't plug in any more devices.

The last time I looked at the Micricum example (so now 2.5 - 3 yrs ago) it was initializing the pinmux and PLL configuration .. basically overwriting what HalCoGen was doing. This made sense since they developed based on a very alpha version of HalCoGen but it wasn't working so well with HalCoGen 3.x ... there were some minor tweeks to make it play well. They were going to take this code out though and leave the device config to HalCoGen. So maybe that is already done in the version you have.
The main things that need to be done for OHCI are to get the pinmux and PLL setup. We have used the 2nd PLL and set its output to 48MHz with USB.

The ports on the HDK are documented in the HDK user's guide - J18 is the USB A connector and is connected to OHCI port 0.
HDK User Guide www.ti.com/.../spnu508b.pdf

Hi Tammy,

What I meant was to make sure that you've configured the header file for enough resources to manage all of the devices that you plan to add to the bus. This would be anything that you are going to plug into the bus. For example are you planning to plug in a hub with keyboard, mouse, thumb drive, etc. ? This will need a lot more resources turned on in the Micrium config file than if you just are supporting a single thumb drive.

The header file that i've got has a pretty big comment section to show how you can determine your resource usage. Do you have this file in the distribution you're working with (usbh_cfg.h?)

Hi. Thank you. We are planning to plug into Host Controller
1. USB memory sticks to transfer files to/from (file system when that is running) on the target hardware
2. Android Tablet (messaging communication to/from)

Yes I do. Is there a way to upload our version of the usbh_cfg.h file on here for you to see it?

Hi. Thank you. I have a meeting with Micrium engineering tomorrow. if they are unable to help resolve I will ask for permission to give TI the files. Thank you again.