> > 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
