On 2/25/19 11:02 PM, Peter Chen wrote:
I suspect the controller is stuck at high speed. Chandler, would you please supply
below information:
- If there is SOFs on the bus (you need to measure by probe) when the issue
occurs?
- If the SOF can't be observed at bus, it means the disconnection
can't be observed either. You could check the portsc.ccs bit if you could
disconnect the HUB by some ways.
No software workaround now, we still don't know the root cause. Would
you please dump below registers at usbphy when the issue occurs:
for (write USBPHY.USBPHYx_DEBUG1n($USBPHY + 0x70) from 1 to 7)
read USBPHY.USBPHYx_DEBUG0_STATUS three times, and delay 10ms
between each read
Record the above 6 values, and tell me, thanks.
Peter
Hi Peter,
I don't currently have access to a probe; is there any you could recommend?
Here is what's in the debugfs registers after failure, including PORTSC:
USBINTR reg: 00000037
USBSTS reg: 000ce088
USBMODE reg: 00000013
USBCMD reg: 00010075
PORTSC reg: 18001a05
By disconnecting the hub do you mean the root hub on the SBC? I might have to
look through the schematic to find a way to reset it electronically.
I would like to know the physical dp/dm change status
- If the dp/dm has NOT changed within 125us, I would like to know if it is SE0 forever
- If the dp/dm has changed within 125us, I would like to view packet signal.
Eg, one screen for 125us, and one screen for 500us.
The above test is used to know which one is wrong, the controller or the external HUB.
Continual read portsc within 125us is also useful, but can't get the conclusion compared
to the physical measurement.
Here is the result of writing values 1 through 7 to DEBUG1 and reading DEBUG0
(with 10ms delay). I hope this is what you want; I had trouble finding
documentation on those registers:
USBPHYx_DEBUG0_STATUS field descriptions
31–26
SQUELCH_
COUNT
Running count of the squelch reset instead of normal end for HS RX.
25–16
UTMI_
RXERROR_
FAIL_COUNT
Running count of the UTMI_RXERROR.
15–0
LOOP_BACK_
FAIL_COUNT
Running count of the failed pseudo-random generator loopback. Each time entering testmode, counter
goes to 900D and will count up for every detected packet failure in digital/analog loopback tests.
1
write 0x00000001 to 0x020CA070
Value at address 0x20CA060 (0xb6f76060): 0x7B2C Value at address 0x20CA060
(0xb6f4a060): 0x7B2C Value at address 0x20CA060 (0xb6fa9060): 0x7B2C
2
write 0x00000002 to 0x020CA070
Value at address 0x20CA060 (0xb6f12060): 0x64 Value at address 0x20CA060
(0xb6f8e060): 0x64 Value at address 0x20CA060 (0xb6fed060): 0x64
3
write 0x00000003 to 0x020CA070
Value at address 0x20CA060 (0xb6f77060): 0x10840108 Value at address
0x20CA060 (0xb6f2f060): 0x10820108 Value at address 0x20CA060 (0xb6f9c060):
0x10804104
4
write 0x00000004 to 0x020CA070
Value at address 0x20CA060 (0xb6fdf060): 0x10001 Value at address 0x20CA060
(0xb6f47060): 0x10001 Value at address 0x20CA060 (0xb6fb2060): 0x10001
5
write 0x00000005 to 0x020CA070
Value at address 0x20CA060 (0xb6f56060): 0x1011101 Value at address
0x20CA060 (0xb6fc2060): 0x1011101 Value at address 0x20CA060 (0xb6f72060):
0x1011101
6
write 0x00000006 to 0x020CA070
Value at address 0x20CA060 (0xb6f31060): 0x101 Value at address 0x20CA060
(0xb6f7a060): 0x101 Value at address 0x20CA060 (0xb6fc8060): 0x101
7
write 0x00000007 to 0x020CA070
Value at address 0x20CA060 (0xb6fe3060): 0x5300010 Value at address
0x20CA060 (0xb6ffa060): 0x5300010 Value at address 0x20CA060 (0xb6f04060):
0x5300010
Chandler
From the above, we know the controller is at RX active status. But I am sorry I got the
imprecise instruction from IC guys. The reason we do that is to know the RX status
change during one packet, for your example, there are ISOC packets, so, measure time
is about 20us. (1024 bytes).
First, you may need to know the time between two reads, it needs to be within 1-10us, then
we need to know all reads within 20us, you could save the read value at memory, and print
it out after all reads are done. Besides, You need to write debug register from 1 to 8 (not 7).
for (write USBPHY.USBPHYx_DEBUG1n($USBPHY + 0x70) from 1 to 8)
read all USBPHY.USBPHYx_DEBUG0_STATUS value within 20us
I am not sure if you could do above at userspace.
Peter
Hi Peter,
I managed to preform those requests in 20uS. The results are not much different.
Time: 18uS
0x020CA060 @ 0x1: 0x00007B2C
0x020CA060 @ 0x2: 0x00000064
0x020CA060 @ 0x3: 0x108401C0 (still changes on every read)
0x020CA060 @ 0x4: 0x00010001
0x020CA060 @ 0x5: 0x01011101
0x020CA060 @ 0x6: 0x00000101
0x020CA060 @ 0x7: 0x05300010
0x020CA060 @ 0x8: 0x81000001
I should mention that PORTSC and other registers (besides the DEBUG0_STATUS @ 3)
don't change at all between reads. I did manage to find a way to reset the root
hub through GPIO, and I see the following changes occur:
PORTSC reg: 18001a05 --> 18001205
0x020CA060 @ 0x2: 0x00000064 --> 0x00000024
After this change the registers remain static and will go back the previous state
after releasing reset.
I will continue looking into probing Dm/Dp. You would like me to do this
*while* the failure occurs, or after?
Thanks,
Chandler
