USB superspeed peripherals

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

Hello,

Our CX3 I2C is not working properly, looks like only sometimes in random we mange to communicate with our camera module. lookin at the signals we see that the rise time is high as well as the frequency is not as it should, it is 250KHz instead of 400KHz. this is with 10K pull-up resistors as it is in the reference design.

we tried changing the pull-up to 5KHz, this had an impact, mainly on the frequency which changed to 280KHz.
Then we saw in the FX3 checklist that it is recommended to use 2K pull-up (it is for flash but we decided to try) and the signal changed to 400KHz but the rise time is still bad

any suggestions? there is nothing on the I2C lines that is loading them (the signals remain similar with and without the camera module).

attached also the schematics and layout.

thanks, 

Hi,

  I am working on a Denebola CX3 Kit which comes with a OV5640 image sensor. I used the sample application "Cx3UvcOV5640" and flashed the board. I am able to see the video on e-CamView and it works fine. I am trying to get some logs from the device so that I can view it on my serial console (Tera term). The USB COM port comes up on the PC, but I am not able to see any messages.

I am sending messages via the serial console using CyU3PDebugPrint().  CX3_DEBUG_ENABLED  is also set to 1.

Any idea why I am not seeing the debug logs on my PC.

Please provide any examples to view serial logs.

Thanks and Regards,

Subbu

Hello experts,

I trying to design a host application to update the firmware of my device. I am following CyControlCenter.pdf provided in the SDK  -->C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\application\c_sharp.

I have struck up at  one place i.e., the devices which are in bootloader mode can only be detected by Control center and shown up in Device tree. I am trying to imitate this behavior in such a way that my application needs to detect the devices which are in device mode and needs to communicate with it further.

Is it possible to communicate with devices which are in device mode?

If yes, could you please give a hint to do this?

Thank you,

Shafi.

Hi,

I am working on a Denebola CX3 Kit which comes with a OV5640 image sensor. I used the sample application "Cx3UvcOV5640" and flashed the board. I am able to see the video on e-CamView and it works fine.

I would like to control a peripheral, other than the camera I2C, which is connected to CAM_I2C_SDA and CAM_I2C_SCL on the MIPI connector.

How do I configure it and transmit/receive to the peripheral ?

I see the API CyU3PMipicsiInitializeI2c() which should initialize the I2C interface. How do I transmit and receive to this I2C interface. Is there any MipiI2c transmit and receive APIs available? Any examples you can point to me will be really helpful.

Thanks and Regards,

Subbu

Hi, 

I am currently working with CX3 device in order to get full-frame from CIS sensor. I have enabled several Processing Units(PU) in order to have a handshaking with sensor, and control it.

It works fine in Windows, working under UVC. But I am having problems in Ubuntu, working under V4L2.

It is a few strange, because the device is running with the same firmware, so I guess there is something wrong either uvcdscr.c or uvc.c file.

Please, could you tell me if it's common having problems between UVC and V4L2? Have I to configure the Processing Units on different way?

I have attached both uvcdscr.c and uvc.c files.

Thanks so much.

I Load the GPIF configuration for Slave FIFO sync mode.

And start GPIF state machine by using this api CyU3PGpifSMStart(RESET, ALPHA_RESET);

Whole configuration is done like 

###### See GPIF_config.PNG  ##### 

Now I need the RESET the GPIF configuration.

###  see attach file GPIF_reset.PNG ###

I try these api

1) Is this correct ??

2) How to change the State of GPIF by using CyU3PGpifSMSwitch() ??

                          comment : CyU3PGpifSMSwitch() is successful but state is not changed ?

3) If GPIF state change to RESET and then change to IDEAL, Is equivalent to GPIF RESET ??

My requirement is to RD/WR the register from FPGA with RESET whenever user wants.

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

Hi,

I am trying to modify FX3 cyfxmscdemo app to set an interface from usb to fpga over gpif. 
I use the following APIs,
--
In Scsi Read10 case,
CyU3PDmaChannelSetupRecvBuffer (&glChHandleBulkPtoU, &dmaBuf) //  receive from fgpa to temp buffer
CyU3PDmaChannelSetupSendBuffer (&glChHandleBulkPtoU, &dmaBuf) // send temp buffer to usb host

In Scsi Write10 case,
CyU3PDmaChannelSetupRecvBuffer (&glChHandleBulkUtoP, &dmaBuf) //  receive from usb host to temp buffer
CyU3PDmaChannelSetupSendBuffer (&glChHandleBulkUtoP, &dmaBuf) // send temp buffer to fpga
--

However, this temp buffer (glMscStorageDeviceMemory) has limited capacity due to FX3 ram size. 
Current usb3 speeds may send 2048 numBlks (2048x512 byte=1MByte), which cannot be stored in this temp buffer. I can correctly format fpga ddr memory using above functions by limiting numBlks count in Linux side. 

Now, I want to get rid of this buffer and directly send data from usb to fpga and vice versa. Thus, I noticed CyU3PDmaChannelSetXfer() API in cyfx3s_msc app and I changed above functions with the following ones

In Scsi Read10 case,
CyU3PDmaChannelSetXfer(&glChHandleBulkPtoU, numBlks*glLunBlkSize) // send from fpga to usb host(??)

In Scsi Write10 case,
CyU3PDmaChannelSetXfer(&glChHandleBulkUtoP, numBlks*glLunBlkSize) // send from usb host to fpga (??)

I suppose that should directly transfer data in both directions in the dma channels without involving any buffer, right?

The problem is that, host msc driver first sends read10 cmd (lba:0 and numBlks:1). Then fpga correctly send data to usb host. I can both observe that data correctly in fpga chipscope and in Wireshark usb protocol in Linux .  However, Read10 acknowledge does not appear in Wireshark usb protocol.(I think it should come from FX3 msc driver?) And usb connection freezes after that and does not send any further read10 cmds.

I wonder that, is there anything that I am missing? Can't I use CyU3PDmaChannelSetXfer() in this case? How can I further debug?

Thanks in advance.