USB Forcing of Host or Device Mode

We need to set Mode.D7 = 1 to tell the controller to ignore id pin and use software based information to enter either into host or device mode based on Mode.D8 bit.

If Mode.D8 = 0 then its host mode else if Mode.D8 = 1 then its device mode.

Ajay

The UTMI defined IDDIG signal that is sourced by the PHY and is connected to the USB OTG controller is used to indicate the resistance connected to the ID pin of the mini/micro-AB receptacle.  The legacy OTG specification required the ID pin to have less than 10 ohms connected to ground when a mini/micro-A plug is inserted into the mini/micro-AB receptacle.  This would indicate the USB port should operate in host mode.  If the ID pin had greater than 100K ohms connected to ground, this would indicate a mini/micro-B plug is inserted into the mini/micro-AB receptacle and the USB port should operate in peripheral mode.

A two input multiplexer was inserted in the path of the IDDIG signal such that one input is connected to the PHY IDDIG output, the other input is connected to bit 8 of the respective USBxMODE register, the output is connected to the USB OTG controller IDDIG input, and the multiplexer control input is connected to bit 7 of the respective USBxMODE register.  This circuit was added to the USB subsystem because a few TI devices using the same USB subsystem did not need OTG functionality and wanted to save one package terminal by not connecting the ID silicon pad to a package terminal.  In this case they needed a way to force the IDDIG signal going into the USB OTG controller.  Since the AM335x has the ID pad connected to a package terminal, it is not necessary to use this circuit to force the IDDIG signal.  The AM335x ID terminal can be connected directly to ground if the respective USB port is configured to only operate as USB host and can be open-circuit if the respective USB port is configured to only operate as USB peripheral.  However, the AM335x ID terminal must be connected to the ID pin of the mini/micro-AB receptacle if the USB port is configured to operate as a dual-role USB OTG device.

The USB OTG controller uses the state of the IDDIG signal as one indicator when determining the mode of operation.  I know at least one exception where the state of the IDDIG is ignored.  If VBUS is applied before the host session is started, the USB OTG controller assumes it is already connected to another host and will enter device mode.  This is done to prevent two sources from driving VBUS at the same time.

The TRM should have bit 7 described in the USB0MODE and USB0MODE Register Field Descriptions table.  I will submit the update to the person responsible for the TRM.

If you do not connect VBUS the USB OTG controller will not get a valid VBUS indication from the UTMI defined VBUSVALID signal.  This causes the USB OTG controller operating in host mode to think there is an over-current condition because it monitors the state of the VBUSVALID signal to determine if the voltage is greater than 4.4 volts and assumes the current limited VBUS source is in an over-current state if the PHY does not drive the VBUSVALID signal high.

The SOFTCONN bit turns on the 1.5K ohm pull-up on the DP signal when operating in peripheral mode.  This will indicate a FS/HS peripheral is connected to the host.

Regards,
Paul 

Apparently at least on of my problems is that I  can not find the POWER register description or its address in spruh73.pdf

Paul, your description about USBxMODE register usage is really much more clearer than TRM one. Thanks. I would suggest they could cut and paste it in a future revision of the TRM.

The missing description of bit-7 already arose several months ago, in a post I wrote (http://e2e.ti.com/support/dsp/sitara_arm174_microprocessors/f/791/t/171130.aspx). But I have one more question related to it and to that old thread: why does kernel driver ignore to set bit-7 in ti81xx_musb_set_mode? When kernel is built for am335x, just bit-8 is written depending on host or peripheral role, so looking at your description this would be totally useless: bit-7 is 0 thus ID pin will be driven to PHY IDDIG input, ignoring bit-8 value. Isn't it?

Could you help me to clarify this point? Thanks in advance for you support.

Regards, Max

I 'm not able to answer your questions about the kernel driver.  I will try to get someone from the software team to answer this question.

Regards,
Paul

Linux driver uses ID pin data from connector and so doesn;t set mode.d7 bit.

Ajay

I understand this work perfectly with EVM. But as described by Paul, it should be totally useless to set mode.b8 without setting mode.b7 (and I would prefer not to do useless things). Maybe this driver is used also by platforms other than ti81xx and am335x, therefore that setting must be there for others, I do not know.

In my humble opinion, this kernel driver, as it is, plus not-really-clear and partial info in TRM do not help too much developers to do the right thing to make their own designed board working. And I suppose that TI does not develop PSP as much as a demo software for its EVM boards, but rather as a useful tool for its customers to develop their own products. For this reason, having a kernel driver that make assumptions on HW design options does not seem a good idea to me.

I would suggest to move this info (USB_ID pins connected properly, or need to override them through mode register) outside of the driver using platform data structure to convey it inside the driver. The field 'mode' in omap_musb_board_data is 8 bits long, but musb_mode to be conveyed is just a 2-bits value. Ajay, you have already split that field in two 4-bit fields to convey the musb_mode for both of the USB ports. I would use one of the remaining unused two bits per port to convey this further info. Something like this:

mode[0:2] : USB0 port musb_mode
mode[3]   : USB0 port ID-override
mode[4]   : unused
mode[4:5] : USB1 port musb_mode
mode[6]   : USB1 port ID-override
mode[7]   : unused

In case the ID-override bit is true, the driver would set the mode.b7 to 1, and mode.b8 accordingly to musb_mode. If false, mode register would not be modified. If there is any need of compatibility with platforms other than ti81xx and am335x, you could always set mode.b8 as it is now.

In this way HW-design specific dependencies would be just in the board-specific file (arch/arm/mach-omap2/board-xxx.c), and I think it could be easier for customers to identify parameters to be modified to make their hw working fine.

That's just my suggestion, there could be better way to do it. Hope can helps.

Regards,

Max

Can I ask: has anybody actually tested that setting the USBnMODE register bits actually works for forcing Host mode?

Our software team is reporting that in the USBnMODE registers they configure bit 7 to '1' and bit 8 to '0', however it makes no difference, and even with these bit settings they still need to tie the physical ID pin to GND to get USB Host mode to work.

I can't yet rule out we're doing something wrong, but for a sanity check I wanted to ask if anyone else has had success with software-forcing of Host mode, with the ID pin left floating.

Thanks.

We have implemented CDC-ACM as device and Flash drive as Host. The Host is tied to Ground. The Device is floating.

Thanks for the reply. So you used the hardware method of setting Host mode (ID pin to GND), and not the software method (USBnMODE register bits 7 & 8) then. That's the method we have working as well, but no luck yet with the software method.

I don't recall if I wrote these or just modified them. But I have them in usb.c. I still use both of them, but as I said we tied Host to ground and device is floating.

void USBHostMode(unsigned int ulBase)
{
    /* Check the arguments. */
    ASSERT((ulBase == USB0_BASE)||(ulBase == USB1_BASE));

    /* Set the USB controller mode to host. */
//    HWREGB(ulBase + USB_O_GPCS) &= ~(USB_GPCS_DEVMOD);
//    HWREGH(ulBase + 0XE8) = 0x100; //Forcing Device Mode (B)
//    HWREGH(ulBase + 0xE8) = 0x0; //Forcing Host Mode (A)
    HWREG(ulBase + 0xE8) = 0x80; //Forcing Host Mode (A) bpb set bit 7 to tell it
                                  //to ignore id pin. bit 7 is not documented in
                                  //spruh73f.pdf
}
void USBDeviceMode(unsigned int ulBase)
{
    //Check the arguments
//    ASSERT((ulBase == USB0_BASE)||(ulBase == USB1_BASE));

    //Set the USB controller mode to device
//    HWREGB(ulBase + USB_O_GPCS) &= ~(USB_GPCS_DEVMOD);
    HWREG(ulBase + 0XE8) = 0x180; //Forcing Device Mode (B) bpb set bit 7 to tell it
                                   //to ignore id pin. set bit 8 to tell it device.
                                   // bit 7 is not documented in spruh73f.pdf
}

Frank,

In our board first design we had two USB ports, one Host and one Peripheral, but both the ID pins were left floating. I spent a lot of time to make Host port working, because Linux driver set just bit 8 and not the undocumented bit 7, but finally it worked with success. That's our case but cannot assure it is the 'common' case, because that HW design has some other peculiarities, such as not-really-compliant VBUS connections and so on.

In the second design revision ID pin for Host port has been grounded.

Regards, Max

Frank, did you resolve your issue with the software over-ride of the ID pin?

Regards,
Paul

Not yet Paul, and actually I was going to reply to say Thank You to Max for his reply. It was interesting to read he actually got it working (ie, software override of the ID pin). We haven't managed that yet, but I've forwarded this discussion to our software team for their review. Paul, do you know if TI has managed to do this?

Thanks.

I have no issue to use the Mode register to control the host or device mode, either modifying ti81xx.c or using devmem2 to directly change the register from command line. The h/w ID pin connection is irrelevant when Mode register is used.

We're running into a similar problem here.

After forcing the USB into host only mode, we got the following error messages:

[    4.896292] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in a_wait_vrise (80, <SessEnd), retry #3, port1 0008010c

[    4.959176] musb-hdrc musb-hdrc.1.auto: VBUS_ERROR in a_wait_vrise (80, <SessEnd), retry #3, port1 0008010c

By measuring the USBx_DRVVBUS signals with an oscilloscope, they are only driven high for a short period. According to the reference manual, the USBx_DRVVBUS signals are controlled by the USB PHY directly.

Can you confirm if the USBx_VBUS signals can be left floating or not?

Thanks

What device is it? and what kernel? the log seems telling that you are not using any TI released SDK/kernel.

Jmax604 said:

Can you confirm if the USBx_VBUS signals can be left floating or not?

Did you mean USBx_VBUS or other pin? For host-only mode, USBx_VBUS should be connected to the power switch, and the VBUS pin of the receptacle as while.

It is customized board with AM3352. The kernel is 3.14. No, it's not TI SDK but Ubuntu ARM.

Yes, I meant the USBx_VBUS pins. They are not connected in our design.

So, the USBx_VBUS pins must be connected to a 5V source even in host only mode, correct?

Gordon Li said:

Yes, I meant the USBx_VBUS pins. They are not connected in our design.

I believe this is the reason why you got the VBUS ERROR in the log.

Gordon Li said:

So, the USBx_VBUS pins must be connected to a 5V source even in host only mode, correct?

Yes. We recommend USBx_VBUS to be connected to a power switch which is controlled by USBx_DRVVBUS, as in the design of the host port in our EVMs.

You could also directly tie USBx_VBUS to a 5V rail, then you have to apply the patch in the link below. Please note this patch is for USB0 port in host-only mode. If you use USB1 port, please change to 'if (id ==1)' in the patch.

http://e2e.ti.com/support/arm/sitara_arm/f/791/p/331883/1193892.aspx#1193892

Please also put a minimum 120uF cap on VBUS (also in the EVM reference design), as required in the USB2.0 Specs. Otherwise, some none USB Specs compliant devices will cause VBUS ERROR.

Please note the patch in the link above is only tested with TI Linux SDK 7.0, not other kernels.

Thanks for the quick responde.

I will modify the board to have the USBx_VBUS pins connected.

Have a nice day!