USB superspeed peripherals

I designed a USB test module using CYUSB3014. This USB test module is used to test the USB HUB. The module runs the cyfxbulksrcsink example, and the circuit design completely refers to CYUSB3KIT-003.

I simulated some open-circuit and short-circuit faults of the superspeed signal on the USB HUB side, and then verified whether these faults can be detected by the CYUSB3014 module, and found that the following three fault tests failed:

1. SSRX_N open: Enumeration and data communication are completely normal.
2. SSTX_P shorted to GND: Enumeration and data communication are completely normal.
3. SSTX_N shorted to GND: Enumeration and data communication are completely normal.
4. SSRX_P shorted to GND: Enumeration and data communication are completely normal.
5. SSRX_N shorted to GND: Enumeration and data communication are completely normal.

What's the problem?

Is it possible to modify the firmware to solve all or some of the above problems?

If it can't be solved by modifying the firmware, what hardware circuit can solve the above problems, I hope to get your suggestions.

Hi,

I've written a custom bootloader for the CYUSB3014-BZXC using the Cypress Boot API. We've been using this bootloader without issue for the past couple of months. However, someone recently plugged the board into a USB 3.1 host controller using a USB 2.0 cable. Upon doing so we discovered that in USB 2.0 mode the device stops responding to standard requests after being suspended and then resumed. The traffic on the USB bus was captured with an Ellisys EX350 and shows the following transactions:

1. get device descriptor (success)
2. set address (success)
3. get device descriptor (success)
4. get configuration descriptor (success)
5. get BOS ddescriptor (success)
6. get serial number descriptor (success)
7. get language ID descriptor (success)
8. get product descriptor (success)
9. set configuration 1 (success)
10. LPM transaction (success)
11. Suspended
12. Resume
13. get language ID descriptor x 6 (failure)
14. get manufacturer descriptor x 6 (failure)
15. get product descriptor x 6 (failure)

UART Debug message prints from the firmware show the following:

Initializing FX3 Boot Firmware 1.6
Boot FW Event: CY_FX3_BOOT_USB_IN_SS_DISCONNECT
Boot FW Event: CY_FX3_BOOT_USB_SUSPEND
Boot FW Event: CY_FX3_BOOT_USB_RESET
Boot FW Event: CY_FX3_BOOT_USB_RESET
Boot FW Event: CY_FX3_BOOT_USB_RESUME

Are there any special actions that the firmware must take when it receives CY_FX3_BOOT_USB_SUSPEND or CY_FX3_BOOT_USB_RESUME in order to get the FX3 to ACK the control requests that take place after the the suspend and resume operations?

We also seem to experience the same problem when running the application firmware (uses Cypress full API) when the device is plugged in with a USB 2.0 cable. The bus activity is similar:

1. get device descriptor (success)
2. set address (success)
3. get device descriptor (success)
4. get configuration descriptor (success)
5. get BOS ddescriptor (success)
6. get serial number descriptor (success)
7. get language ID descriptor (success)
8. get product descriptor (success)
9. LPM transaction (success)
10. Suspended
11. Resume
12. set configuration 1 x 3 (failure)
13. Suspended

So the same question applies for the application firmware: what steps must we take in firmware in order for control transfers to succeed after the device has been suspended and then resumed?

Some other information that you may find useful:

Operating system: Windows 10
Host Controller: Asmedia ASM3142
Hub: none

I appreciate any help you can provide.

Thanks,
Michael

Hi,

I've created a custom bootloader for the CYUSB3014-BZXC using the Cypress Boot API. The bootloader supports application firmware download to RAM using a vendor request very similar to the Fx3BootAppGcc example. The host downloads the application firmware to the device in 4096 byte chunks. Testing has shown that application firmware download works reliably across many different hardware configurations and operating systems. However, I have identified a system and OS where firmware download fails unless I reduce the chunk size to 512 bytes.

I have a system that runs both Ubuntu 20.04.4 LTS 64-bit and Windows 10 64-bit. Firmware download works correctly under Windows 10, regardless of connection speed. However, it fails under Ubuntu when the device is connected through a USB 3 cable to a USB 3 port. I performed a packet capture with the Ellisys EX350 and found that the bootloader acks the first 512 bytes of a 4096 byte setup request but then fails to acknowledge the next 512 bytes of the data stage after previously sending an ERDY for control endpoint 0.

I added some UART debug prints and found that the firmware is getting stuck inside of CyFx3BootUsbDmaXferData and will eventually return CY_FX3_BOOT_ERROR_ABORTED, but only after the next setup packet is received, which doesn't happen until our software is restarted because it errors out when the host is unable to complete the previous control transfer.

If I connect the board to the same USB port using a USB 2.0 cable then firmware download is successful.

If I connect the board to the same USB port using a USB 3.0 cable and run the software in Windows 10 instead of Linux, then the firmware download is successful.

If I modify our host software to send data in 512 byte chunks then firmware download succeeds but it takes approximately 2.2 seconds to complete instead of 286 milliseconds. Therefore, reducing the transfer size is not an acceptable solution.

I performed packet captures in both Windows and Linux but couldn't identify any notable differences in the first control transfer, other than it succeeds in Windows and the device fails to respond to the OUT packets in Linux.

Can someone please help me figure out why this is failing in Linux? Obviously the host controller driver is different, but like I said I can't see any obvious differences in bus activity.

I can send the bus activity log but the files are too large to attach so they will need to be sent via OneDrive, which requires an email address.

Thanks,
Michael

CyU3PMemSet（（uint8_t *）&dmaConfig，0，sizeof（CyU3PDmaChannelConfig_t））;
dmaConfig.size = CY_FX_UVC_STREAM_BUF_SIZE;
dmaConfig.count = CY_FX_UVC_STREAM_BUF_COUNT;
dmaConfig.prodSckId = （CyU3PDmaSocketId_t）CY_U3P_PIB_SOCKET_0;
dmaConfig.consSckId = （CyU3PDmaSocketId_t）（CY_U3P_UIB_SOCKET_CONS_0 |CY_FX_EP_VIDEO_CONS_SOCKET）;
dmaConfig.prodAvailCount = 0;
dmaConfig.prodHeader = 12; /* 要添加的 12 字节 UVC 标头。 */
dmaConfig.prodFooter = 4; /* 4 字节页脚以补偿 12 字节标头。 */
dmaConfig.consHeader = 0;
dmaConfig.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmaConfig.notification = CY_U3P_DMA_CB_PROD_EVENT;//CY_U3P_DMA_CB_PROD_EVENT ;;
dmaConfig.cb = CyFxUvcApplnDmaCallback;
apiRetStatus = CyU3PDmaChannelCreate （&glChHandleUVCStream，/*CY_U3P_DMA_TYPE_AUTO_SIGNAL*/ CY_U3P_DMA_TYPE_MANUAL，
&dmaConfig）;
if （apiRetStatus ！= CY_U3P_SUCCESS）
{
/* 错误处理 */
CyU3PDebugPrint （4， “DMA 通道创建失败， 错误代码 = %d\n”， apiRetStatus）;
CyFxAppErrorHandler （apiRetStatus）;
}

My hardware is a sensor connected to 3014 via DVP. The problem is the DVP signals are good(frame/line valid and the pixel clock).  And we can see the firmware enter the CyFxUvcApplnDmaCallback(), however, then get the buffer from CyU3PDmaMultiChannelGetBuffer(), we found the dmaBuffer.count  is zero for every callback. The consequence is that the USB host receives many empty USB packages, and no image is presented. 

The interesting thing is if we try to reset 3014(may need a few times), it is probably recovering from the exception state.

Any idea for what's going on under this phenomenon?  Many thanks

Rossi

我使用的型号是：CYUSB3013，现在通过GPIO53~56作为串口，不能输出信息，官方UVC工程连接：https ://www.cypress.com/documentation/application-notes/an755-implement -图像传感器接口使用 ez-usb-fx3-usb

How CyAPI recovers data transmission after accidental USB reconnection

我们当前的解决方案是手动触发CYAPI通过Control End Point通道向CYUSB3014发送一条命令，CYUSB3014固件执行CyU3PDeviceReset函数。这个解决方案存在2个问题。

Our current solution is to manually trigger the CyAPI to send a command to CYUSB3014 through the EP0(Control End Point) channel. The CYUSB3014 firmware executes the CyU3PDeviceReset function. There are two problems with this solution.

第1个：USB连接恢复后的第一次传输异常（后续的传输是成功的）。我们的分析认为CYUSB3014没有清空上次传输失败的数据。如果不调用CyU3PDeviceReset函数，我们就不知道有什么办法恢复CYUSB3014的数据传输。我们尝试过调用CyU3PUsbResetEndpointMemories函数和CyU3PUsbResetEp函数，都没有解决问题。

First: The first transmission fails after the USB connection is restored (the subsequent transmission is successful). Our analysis shows that CYUSB3014 does not clear the data that failed in the last transmission. If the CyU3PDeviceReset function is not called, we do not know how to recover the data transmission of CYUSB3014. We tried to call the CyU3PUsbResetEndpointMemories function and CyU3PUsbResetEp function, but they didn't solve the problem.

第2个：Windows设备管理器会再次刷新。USB连接重连造成Windows设备管理器第1次刷新，CYUSB3014固件执行CyU3PDeviceReset函数后Windows设备管理器发生第2次刷新。我们不希望Windows设备管理器第2次刷新。

Second: Windows Device Manager will refresh again. The reconnection of the USB connection caused the first refresh of the Windows Device Manager, and the second refresh of the Windows Device Manager occurred after the CYUSB3014 firmware executed the CyU3PDeviceReset function. We do not want Windows Device Manager to refresh for the second time.

请指点。谢谢！

Please point out. Thank you!