Problem with OTG configuration on AM3715

Rostislav Stepanov

Other Parts Discussed in Thread: AM3715

Hi,

I have a problem with OTG configuration on AM3715

It uses Mentor Graphics USB controller that talks to ULPI chip SMSC3330 as PHY.

I configured the system that at power up PHY properly sets pull-up on the USB lines. The Host machine sets the reset condition on the lines and I see that using a USB protocol analyzer.

The Mentor graphics controller (MUSB) gets data over ULPI from PHY. I do not have a chance to see that data, but I suppose that it is correct.

The MUSB generates interrupt. Till the moment everything operates as expected.

By some reason MUSB generates interrupt “Start session” as Host, but I set the MUSB as a device (register at address 0x60 is 0x80). Device should generate interrupt “Reset”.

Following are MUSB registers:

address: 0x480AB000, range: 256 bytes

00 E0 00 00 00 00 FF FF FE FF 00 F7 00 00 0F 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 33

1D 00 00 00 20 00 00 00 43 00 00 00 09 00 00 00

71 00 00 00 0D 00 00 00 ED 00 00 00 32 00 00 00

22 00 00 00 61 00 00 00 A9 00 00 00 11 00 00 00

51 00 00 00 58 00 00 00 7E 00 00 00 B3 00 00 00

80 00 07 07 80 07 80 07 00 00 00 00 20 07 00 00

00 00 00 00 45 04 04 00 FF 8C 5C 3C 80 77 72 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Thank you in advance.

over 13 years ago

0 Rostislav Stepanov over 13 years ago

Prodigy 250 points

The exact interrupt name that happens instead of "Reset" in the manual "Sess Req" not “Start session”.

0 peaves over 13 years ago in reply to Rostislav Stepanov

TI__Guru 62855 points

The ID pin needs to be connected to ground when operating as USB host and open-circuit when operating as USB peripheral.

How is your ID pin connected?

Regards,

Paul

0 Rostislav Stepanov over 13 years ago in reply to peaves

Prodigy 250 points

PIN ID is floating and the PHY's internal pull up 100K is enabled.

0 Rostislav Stepanov over 13 years ago in reply to Rostislav Stepanov

Prodigy 250 points

Some additional information:

I grabbed the MUSB registers writing sequence.for Mistral board with operating OTG and for my target. It looks similar till interrupt masks setting code (approximately).

My code does one extra read from DevCtl. I suppose that couldn't affect the device operation.

By some unclear to me reason the INTRUSB for test board returns 0x40 for target board. Mistarl board does 0x01. That means the interrupt reason is "Suspend" for Mistral and "Sess Req" for my board.

Non operating (target board)

__musb_readb addr: fa0ab060 val 80
__musb_readb addr: fa0ab060 val 80
musb_writew addr: fa0ab006 val FFFF
musb_writew addr: fa0ab008 val FFFE
__musb_writeb addr: fa0ab00b val F7
__musb_writeb addr: fa0ab00f val 0
__musb_writeb addr: fa0ab001 val E0
__musb_readb addr: fa0ab060 val 80
__musb_writeb addr: fa0ab060 val 81
__musb_readb addr: fa0ab00a val 40
musb_readw addr: fa0ab002 val 0
musb_readw addr: fa0ab004 val 0
__musb_readb addr: fa0ab060 val 80
__musb_readb addr: fa0ab001 val E0

Operating (Mistral board):

__musb_readb addr: fa0ab060 val 80
musb_writew addr: fa0ab006 val FFFF
musb_writew addr: fa0ab008 val FFFE
__musb_writeb addr: fa0ab00b val F7
__musb_writeb addr: fa0ab00f val 0
__musb_writeb addr: fa0ab001 val E0
__musb_readb addr: fa0ab060 val 80
__musb_writeb addr: fa0ab060 val 81
__musb_readb addr: fa0ab00a val 1
musb_readw addr: fa0ab002 val 0
musb_readw addr: fa0ab004 val 0
__musb_readb addr: fa0ab060 val 99
__musb_readb addr: fa0ab001 val E0

0 Ajay over 13 years ago in reply to Rostislav Stepanov

TI__Genius 9460 points

It seems Vbus from HOST is not reaching to your port as DEVCTL register offset 0x60 value shows as 0x80 and its D[3:4] bit is binary '00'. it should have been bianry '11' which means Vbus is at 5Volt. Check you Vbus circuitry.

Ajay

0 Rostislav Stepanov over 13 years ago in reply to Ajay

Prodigy 250 points

Ajay,

Thank you for information. I believe that it is a reason, but we need to modify hardware to test, so it takes some time.

0 Jiansheng Liu over 13 years ago in reply to Ajay

Intellectual 310 points

Ajay,

Question: are the bit D[3:4] of 0x80 corresponding to VBUS status of RXCMD? In out PHY these status are encoded in d[2:3] instead of [3:4]. Can you help to double check it please?

thanks!

Jiansheng

0 peaves over 13 years ago in reply to Jiansheng Liu

TI__Guru 62855 points

The VBUS status bits are located in bits D[4:3] of the DEVCTL register located at address offset 0x60.

Regards,

Paul

0 Rostislav Stepanov over 13 years ago in reply to Ajay

Prodigy 250 points


Ajay,

In the text below I use address instead of ULPI PHY register name for:

Function Control 0x04

Interface Control 0x07

OTG control 0x0A

OTG control set 0x0B

We found that the PHY has a configuration to mask the Vbus pin status with setting the indicator output to high.

The configuration may be acheived with setting register 0x07 bit 0x40 and registers 0x0A bit 8 to high both.

Unfortunately if we set them both the register 0x0A changes its value to 0x06: no ID pull up and no D+ pull up.

Any attempt to write 0x85 0r 0x05 to register 0x0A is ignored.

Following code sets the bits in the board initialization:

	otg_tr = otg_ulpi_create(&musb_ulpi_access,
	ULPI_FC_TERMSEL | ULPI_OTG_DP_PULLDOWN_DIS | ULPI_OTG_ID_PULLUP | ULPI_OTG_EXTVBUSIND);

With ULPI_IC_IND_PASSTHRU

00 24 04 0C 00 45 45 45 00 00 00 85 85 85 1F 1F 1F
10 1F 1F 1F 18 00 01 AA AA AA 00 00 00 00 00 00 00
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 FF 00 00 00 00 04 04 04 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

With ULPI_IC_IND_PASSTHRU, but without ULPI_OTG_EXTVBUSIND

	otg_tr = otg_ulpi_create(&musb_ulpi_access,
	ULPI_FC_TERMSEL | ULPI_OTG_DP_PULLDOWN_DIS | ULPI_OTG_ID_PULLUP | ULPI_IC_IND_PASSTHRU );

00 24 04 0C 00 45 45 45 40 40 40 05 05 05 1F 1F 1F
10 1F 1F 1F 18 00 01 AA AA AA 00 00 00 00 00 00 00
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 FF 00 00 00 00 04 04 04 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Both ULPI_IC_IND_PASSTHRU are set ULPI_OTG_EXTVBUSIND

Register 0x0A resets the bit 0x80 itself and I am unable to modify it to any value bur 0x06.

00 24 04 0C 00 45 45 45 40 40 40 06 06 06 1F 1F 1F
10 1F 1F 1F 18 02 00 AA AA AA 00 00 00 00 00 00 00
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 FF 00 00 00 00 04 04 04 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

We asked the chip vendor SMSC about this behaviour of the PHY, but they told us that the PHY has no any register dependence on each other.

They insist that it is the LINK who is responsible.

I added tracing prints in MUSB low level read and write functions to see if anything except the ULPI access happens. I don't see anything (the log is following)

All values are in hex:

Write reg: 07  val: 40

__musb_readb addr: fa0ab001 val E0
 __musb_writeb addr: fa0ab001 val E0
 __musb_writeb addr: fa0ab075 val 7
 __musb_writeb addr: fa0ab074 val 40
 __musb_writeb addr: fa0ab076 val 1
 __musb_readb addr: fa0ab076 val 1
 __musb_readb addr: fa0ab076 val 2
 __musb_readb addr: fa0ab076 val 2
 __musb_writeb addr: fa0ab076 val 0

Write reg: 0B  val: 80

__musb_readb addr: fa0ab001 val E0
__musb_writeb addr: fa0ab001 val E0
__musb_writeb addr: fa0ab075 val B
__musb_writeb addr: fa0ab074 val 80
__musb_writeb addr: fa0ab076 val 1
__musb_readb addr: fa0ab076 val 1
__musb_readb addr: fa0ab076 val 2
__musb_readb addr: fa0ab076 val 2
__musb_writeb addr: fa0ab076 val 0

Question:

Does MUSB itself write anything to ULPI that modifies the registers?

Thank you,

Rostislav

0 Rostislav Stepanov over 13 years ago in reply to Rostislav Stepanov

Prodigy 250 points

In Mozilla and Chrome long lines are not completely visible.

I replicated the previous post to correct this issue.

Ajay,

In the text below I use address instead of ULPI PHY register name for:

Function Control 0x04

Interface Control 0x07

OTG control 0x0A

OTG control set 0x0B

We found that the PHY has a configuration to mask the Vbus pin status

with setting the indicator output to high.

The configuration may be acheived with setting register 0x07 bit 0x40

and registers 0x0A bit 8 to high both.

Unfortunately if we set them both the register 0x0A changes its value

to 0x06: no ID pull up and no D+ pull up.

Any attempt to write 0x85 0r 0x05 to register 0x0A is ignored.

Following code sets the bits in the board initialization:

	otg_tr = otg_ulpi_create(&musb_ulpi_access,
	ULPI_FC_TERMSEL | ULPI_OTG_DP_PULLDOWN_DIS | ULPI_OTG_ID_PULLUP | ULPI_OTG_EXTVBUSIND);

With ULPI_IC_IND_PASSTHRU

00 24 04 0C 00 45 45 45 00 00 00 85 85 85 1F 1F 1F
10 1F 1F 1F 18 00 01 AA AA AA 00 00 00 00 00 00 00
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 FF 00 00 00 00 04 04 04 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

With ULPI_IC_IND_PASSTHRU, but without ULPI_OTG_EXTVBUSIND

	otg_tr = otg_ulpi_create(&musb_ulpi_access,
	ULPI_FC_TERMSEL | ULPI_OTG_DP_PULLDOWN_DIS | ULPI_OTG_ID_PULLUP | ULPI_IC_IND_PASSTHRU );

00 24 04 0C 00 45 45 45 40 40 40 05 05 05 1F 1F 1F
10 1F 1F 1F 18 00 01 AA AA AA 00 00 00 00 00 00 00
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 FF 00 00 00 00 04 04 04 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Both ULPI_IC_IND_PASSTHRU are set ULPI_OTG_EXTVBUSIND

Register 0x0A resets the bit 0x80 itself and I am unable to modify it to any value bur 0x06.

00 24 04 0C 00 45 45 45 40 40 40 06 06 06 1F 1F 1F
10 1F 1F 1F 18 02 00 AA AA AA 00 00 00 00 00 00 00
20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30 00 00 00 00 FF 00 00 00 00 04 04 04 00 00 00 00
40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

We asked the chip vendor SMSC about this behaviour of the PHY, but they

told us that the PHY has no any register dependence on each other.

They insist that it is the LINK who is responsible.

I added tracing prints in MUSB low level read and write functions to see

if anything except the ULPI access happens. I don't see anything (the log is following)

All values are in hex:

Write reg: 07  val: 40

__musb_readb addr: fa0ab001 val E0
 __musb_writeb addr: fa0ab001 val E0
 __musb_writeb addr: fa0ab075 val 7
 __musb_writeb addr: fa0ab074 val 40
 __musb_writeb addr: fa0ab076 val 1
 __musb_readb addr: fa0ab076 val 1
 __musb_readb addr: fa0ab076 val 2
 __musb_readb addr: fa0ab076 val 2
 __musb_writeb addr: fa0ab076 val 0

Write reg: 0B  val: 80

__musb_readb addr: fa0ab001 val E0
__musb_writeb addr: fa0ab001 val E0
__musb_writeb addr: fa0ab075 val B
__musb_writeb addr: fa0ab074 val 80
__musb_writeb addr: fa0ab076 val 1
__musb_readb addr: fa0ab076 val 1
__musb_readb addr: fa0ab076 val 2
__musb_readb addr: fa0ab076 val 2
__musb_writeb addr: fa0ab076 val 0

Question:

Does MUSB itself write anything to ULPI that modifies the registers?

Thank you,

Rostislav

0 peaves over 13 years ago in reply to Rostislav Stepanov

TI__Guru 62855 points

I was not able to find the USB3330 data sheet, but assume it includes the circuit shown in the attached figure with an external pin equivalent to the ExternalVBusIndicator input. If so, this circuit will allow you to select the internal VBUS comparator or the external input pin to indicate the status of VBUS.

A normal USB implementation requires one of these options to be used to report the actual VBUS status to the controller for it to comply with the USB specification. In your case the USB implementation is self contained within your product so you may not need to report the actual VBUS status. However, the PHY still needs to see a valid VBUS condition to operate as expected.

I assume the ExternalVBusIndicator input is tied off to a known state and you would like to select this input as a method to force a valid VBUS condition.

The state machine in the OTG controller also controls the PHY via these same registers. So anything you manually write may be over written by the OTG controller.

Regards,

Paul

0 Rostislav Stepanov over 13 years ago in reply to peaves

Prodigy 250 points

Thanks, Paul

Let me clarify one more thing:

Does state machine overwrite the registers beyond the scope of software or the state machine is implemented in the MUSB Linux driver?

Thank you,

Rostislav

0 peaves over 13 years ago in reply to Rostislav Stepanov

TI__Guru 62855 points

I was referencing the hardware state machine in the USB OTG controller. This hardware state machine operates like most hardware, it performs some operations automatically without evolvement from the software driver but its operations are initiated and performed by a combination of software configuration and external events. Therefore, there may be limits to what you can do in preventing the hardware from reconfiguring the PHY by modifying the contents of ULPI registers. I’m not familiar enough with the internal operation of the hardware to tell you if what you are trying to do is possible. This hardware was purchased by Texas Instruments and is normally support from a much higher level of operation.

If you connect VBUS as expected it should resolve this problem.

Regards,

Paul

0 Ajay over 13 years ago in reply to peaves

TI__Genius 9460 points

Rosti,

Linux musb driver doesn;t program any of PHY registers and I expect everything is being done by hardware automatically.

Regards,

Ajay

0 Rostislav Stepanov over 13 years ago in reply to Ajay

Prodigy 250 points

Ajay,

That depends on the Linux kernel version. The version 2.6.37 has such ability. You may examine musb_core.c to find

static int musb_ulpi_read(struct otg_transceiver *otg, u32 offset)

and

static int musb_ulpi_write(struct otg_transceiver *otg, u32 data, u32 offset)

I configured my kernel to watch the registers and modify them using a /proc/ located file. That is the way I got dumps printed in the thread.

OTG configuration bits I mentioned are accessing the PHY bits using the same API.

Rostislav

0 Rostislav Stepanov over 13 years ago in reply to peaves

Prodigy 250 points

Thanks, Paul.

Processors

Processors forum

Problem with OTG configuration on AM3715