How to make USB3320 ULPI work with OMAP4470?

Maggie Roxas

I am using USB3320 ULPI for my OMAP4470, but it's not working (modeled from OMAP4430 Panda which also have USB3320 ULPI).

I have set pin mux of the following:
- RESETB: gpio_61
- CLKOUT: usbb2_ulpiphy_clk
- DIR: usbb2_ulpiphy_dir
- STP: usbb2_ulpiphy_stp
- NXT: usbb2_ulpiphy_nxt
- DAT0: usbb2_ulpiphy_dat0
- DAT1: usbb2_ulpiphy_dat1
- DAT2: usbb2_ulpiphy_dat2
- DAT3: usbb2_ulpiphy_dat3
- DAT4: usbb2_ulpiphy_dat4
- DAT5: usbb2_ulpiphy_dat5
- DAT6: usbb2_ulpiphy_dat6
- DAT7: usbb2_ulpiphy_dat7
- REFCLK: fref_clk2_out

RESETB is OK (high at 1.8v).
CLKOUT is OK (55Mhz).
But REFCLK is NOT OK (always low).

When I compare my schematics with Panda's, the only difference is it used fref_clk3_out (I used fref_clk2_out).
I am not sure if there's a difference in usage of fref_clk2_out.

Any advise on how I can work this out?

Thank you.

over 11 years ago

0 Boyko Kazakov over 11 years ago

TI__Genius 10965 points

Hi Maggie,

Are you trying to test it with u-boot driver?

Regards,

Boyko

0 Maggie Roxas over 11 years ago in reply to Boyko Kazakov

Prodigy 250 points

Sorry, what "u-boot driver"..? Is there a particular u-boot driver for USB3320?

# I test by monitoring the pin signals via oscilloscope, and also plugging in/out actual USB 2.0 device.

# Note: I can boot-up up to android file system, but USB is not working.

0 Boyko Kazakov over 11 years ago in reply to Maggie Roxas

TI__Genius 10965 points

I was asking because maybe the usb3320 is initialized on boot-loader level as well.

Most importantly you must check all registers for clocks that need to be enabled in order that ref-clock to be functional.

You can easily check that with the clock tree tool and examine the PRCM chapter of the TRM.

Regards,

Boyko

0 Maggie Roxas over 11 years ago in reply to Boyko Kazakov

Prodigy 250 points

I was able to set the voltages and clock as required by USB3320C.

RESETB is OK (high at 1.8v).
CLKOUT is OK (60Mhz).
REFCLK is OK (19.2Mhz - we drove fref_clk2_out to 19.2Mhz at board-44xx-tablet.c usbhs initialization)

So basically, the chip is active and working, just that USB inserted does not come up as /dev/block/s**.

No entry in /sys/kernel/debug/usb/devices as well. I only see the EHCI-controller's entry:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 3
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 3.04
S:  Manufacturer=Linux 3.4.48-02203-gff57010-dirty ehci_hcd
S:  Product=OMAP-EHCI Host Controller
S:  SerialNumber=ehci-omap.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

In Panda, which uses the same USB3320 chip, something like this appears when a USB is inserted:

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 3
B:  Alloc=  0/800 us ( 0%), #Int=  2, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 3.00
S:  Manufacturer=Linux 3.0.31-04788-gcb5fc50 ehci_hcd
S:  Product=OMAP-EHCI Host Controller
S:  SerialNumber=ehci-omap.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=8644 ProdID=800b Rev= 1.00
S:  Manufacturer=General                       
S:  Product=USB Flash Disk                
S:  SerialNumber=11334000000031B3
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Is this Android-setup related?

What else could I check?

Thank you.

0 Matt Thomas2 over 11 years ago in reply to Maggie Roxas

Prodigy 60 points

Hi Maggie,

As far as pin mux configuration issues, I found it is best to check the pin mux at runtime. Whatever you put in your board file can be overridden by a number of overlays. The whole board file thing is a mess really, hence the move to device tree in newer (3.8?) kernels.

Anyway, boot your system, get to a console and execute the following:

cat /sys/kernel/debug/omap_mux/board

At least I think that's the file. Basically dig around in the omap_mux folder and grep for usbb2*. All the usbb2_ulpiphy* signals should be set to OMAP_PIN_INPUT_PULLDOWN except for the STP signal, which is an output. Everything should also be mode 1. (At least I think so, my dev board isn't available at the moment, so I can't check myself, I'm only using my usb-host.c file as a reference). As a fun experiment, you can actually change these pinmux configs after the board has booted using echo. The first time I got my bus to work was using echo and watching on an oscilloscope. Embedded is fun!

I know you said your clock is okay, but please double check your clock. Check that you get 60MHz both at the output of your 3320 and at the input to your actual TI OMAP silicon. (BTW, you are getting 60 and not 55, right? You mentioned 55 in your first post and that is not correct, your transceiver's PLL should be locked dead on at 60). Once your pinmux is correct and your clock is being generated by the transceiver, you should be good to go. On my hardware, we actually generated a 12MHz reference clock on our board and fed it to the 3320. The reason for this is we had a few other components running at 12MHz, so we shared the clock between them. So we didn't need the OMAP to generate a clock, although I'm sure it's capable. Sounds like that's what you're doing with a 19.2). Anyway, check again that your 60MHz is coming out of the 3320, and double check it makes it to the OMAP silicon. In my case, the 60MHz was being generated, but there was a schematic flaw that caused the 60MHz to terminate before reaching the chip. For the OMAP4430, it was pin AG12, labeled USBB2_ULPITLL_CLK.

Have you looked at the output of lsusb? It should show a root hub. (It will only show a single root EHCI port, even though the OMAP4 actually has two root ports). You can also try loading the ohci module and another bus should show up. (lsmod, modprobe, etc are your friend... or compile them into the kernel, but it might be useful to have ehci as a loadable module for debugging reasons).

Are you plugging your device directly into the 3320 or do you have a downstream hub? You might want to try using a hub attached to the root port. The hub should show up in lsusb (or in kernel dmesg, or console announcements if you have them turned on). Also, check VBUS output from the 3320. Is it +5V? You should also see D+ or D- go high once the device is plugged in.

0 Maggie Roxas over 11 years ago in reply to Matt Thomas2

Prodigy 250 points

First of all, thanks a lot for looking into my problem.

Matt Thomas2 said:

As far as pin mux configuration issues, I found it is best to check the pin mux at runtime. Whatever you put in your board file can be overridden by a number of overlays. The whole board file thing is a mess really, hence the move to device tree in newer (3.8?) kernels.

Yes, actually I've been monitoring it via /sys/kernel/debug/omap_mux/board as you suggested.

Unfortunately, I'm using a 3.5 kernel without DT support yet.

Matt Thomas2 said:

I know you said your clock is okay, but please double check your clock. Check that you get 60MHz both at the output of your 3320 and at the input to your actual TI OMAP silicon. (BTW, you are getting 60 and not 55, right? You mentioned 55 in your first post and that is not correct, your transceiver's PLL should be locked dead on at 60).

Yes, my CLKOUT at first was at 55Mhz. That was before I drove a 19.2Mhz at REF.

When I set 19.2Mhz clock at REF, my CLKOUT moved to 60Mhz.

Matt Thomas2 said:

Have you looked at the output of lsusb? It should show a root hub. (It will only show a single root EHCI port, even though the OMAP4 actually has two root ports). You can also try loading the ohci module and another bus should show up. (lsmod, modprobe, etc are your friend... or compile them into the kernel, but it might be useful to have ehci as a loadable module for debugging reasons).

I'm using a default Android package without lsusb yet.. So I've been monitoring via cat /sys/kernel/debug/usb/devices which produces the same output.

Matt Thomas2 said:

Are you plugging your device directly into the 3320 or do you have a downstream hub? You might want to try using a hub attached to the root port. The hub should show up in lsusb (or in kernel dmesg, or console announcements if you have them turned on). Also, check VBUS output from the 3320. Is it +5V? You should also see D+ or D- go high once the device is plugged in.

I hardwired a USB cable directly to the chip's D+/D- - ground and power of the cable is attached somewhere else in the board.

As of now I'm not sure how to monitor D+/D- via the oscilloscope..

Nevertheless, I monitored pins of omap_mux at runtime as you mentioned, and it seems like STP and DAT0 is always having an additional WAKEUP, unlike what you've said that it should only be PULLDOWN and MODE1.
So I know from that point that something's wrong - and then I noticed that the D+ (green cable) and D- (white cable) were interchanged!

After fixing that, and given these changes:

arch/arm/mach-omap2/board-44xx-tablet.c (set usbhs_omap_board_data.port_mode[1] to OMAP_EHCI_PORT_MODE_PHY, set "auxclk2_ck" clock rate to 19.2Mhz and enable RESET GPIO as high)
arch/arm/mach-omap2/usb-host.c (copy Panda's settings for USBB1)

This problem is already resolved.

Thank you very much for the advises.

Been using them, and it's good to know that there are others who experienced debugging these aside from me. :)

Processors

Processors forum

How to make USB3320 ULPI work with OMAP4470?