USB superspeed peripherals Forum Discussions

I am seeing that the control center application is only sending 1024 64-byte i2c packets when I try to program the FX3 from bootloader mode.  The image is larger than that.

Using an i2c snooper I can see that the length is 0x4A09 dwords:

Time ,Packet ID,Address,Data,Read/Write,ACK/NAK

0.000090010000000,0,P (0x50),'0' (0x00),Write,ACK

0.000180010000000,0,P (0x50),'0' (0x00),Write,ACK

0.000270010000000,0,P (0x50),C (0x43),Write,ACK

0.000360020000000,0,P (0x50),Y (0x59),Write,ACK

0.000450020000000,0,P (0x50),'30' (0x1E),Write,ACK

0.000540020000000,0,P (0x50),'176' (0xB0),Write,ACK

0.000630030000000,0,P (0x50),J (0x4A),Write,ACK

0.000720030000000,0,P (0x50),\t (0x09),Write,ACK

0.000810030000000,0,P (0x50),'0' (0x00),Write,ACK

0.000900040000000,0,P (0x50),'0' (0x00),Write,ACK

Which matches the .img file contents:

00000000  43 59 1E B0 4A 09 00 00

A couple questions...

1) are the leading two bytes of 0x00 and 0x00 expected to precede the image 'C' and 'Y'?

2) after 1024 64-byte packets the FX3 stops writing to the EEPROM device. 0x4A09 needs 1184 64-byte packets.  How can I get more information out of Control Center?  All I get is the status bar saying that programming failed:

FYI - the EEPROM is ST-Micro M24M02 which is 256k-byte, I'm configuring the image for the largest supported EEPROM size of 128k-byte (0x1E = 00 01 111 0, bits 3:1=7 is 128k-bytes).

quote:

"

If FX3 is operating on a USB 3.0 link with poor signal quality, and there are a

number of protocol level CRC errors and retries happening; the device could get

into a state where it sends incorrect data on any of the IN endpoints (including the

control endpoint). This happens due to a known defect in the way the FX3 device

handles a pre-mature burst transfer termination by the host.

SDK versions 1.3.3 and later introduce a firmware work-around to prevent this kind

of failure. The USB driver in the libraries internally manages (suspends and then

resumes) DMA transfers and performs an Endpoint Memory reset when potential

error conditions are seen.

As an endpoint memory reset will result in some loss of data on the in-flight

endpoint; it is required that the firmware application perform an error recovery on

the corresponding endpoint. This can be done by registering for the

CYU3P_USBEP_SS_RESET_EVT event on all IN endpoints, and performing an

endpoint specific recovery when the event is received. The recommended recovery

procedure is to STALL the endpoint, and then stop and restart the DMA data path

when the CLEAR_FEATURE request is received.

"

1. Is there source code for the firmware that send CYU3P_USBEP_SS_RESET_EVT, or is it sent by some proprietary firmware?

2. What is the standard/recommended way to send CLEAR_FEATURE to the device? My understanding is:

   check status of the device, if it is 0xC0000030 USBD_STATUS_ENDPOINT_HALTED, then inEndpoint.Reset().

   inEndpoint.Reset() will take several seconds which is not acceptable by end users, so this problem have to be eliminated.

3. What does "poor signal quality" mean? I use the cable come with the CYUSB3KIT-003 which can be considered good cable but still get this event. Will every product based on FX3 have such problem? Does product based on FX3 require "excellent cable" to work?

Either no CYU3P_USBEP_SS_RESET_EVT or instant recover from CYU3P_USBEP_SS_RESET_EVT is acceptable by end use, but now both seems to be there.

Hello guys,

We were able to successfully benefit from the application note AN75779 and use FX3 to transfer video streams from our image sensors (IMX250, IMX253, IMX420) to the PC. VLC player has been used to play the streams. Thanks for your support in that sense (thread 1, thread 2)! It is really appreciated.

We are now in the process of replacing VLC player by our custom software using UVC class drivers. In that sense, we would like to be able to dynamically change video resolution during system runtime. Here are some use-cases where this dynamic resolution change would be necessary:

1) During system start-up, we will read the type of the image sensor we have connected with FX3 and set video resolution accordingly.

2) There will be a need to change video mode or simply video resolution during runtime of the system by sending appropriate command message from PC.

In this thread you explained us how to include different resolutions into USB descriptor chain and we did it successfully. We also noticed that the last Class specific Uncompressed VS frame descriptor in the list represents the default video resolution.

Our FX3 firmware is based on AN75779 example. What are the steps/commands to take in order to change video resolution of the stream dynamically, during runtime? We can change a resolution of the image sensor successfully, we only need to inform PC about that.

As always, thank you very much for your time and efforts!

Sincerely,

Bojan.

Some reference Using FX3, what is required to use DMA fabric to link Parallel Port sockets to a CPU using MANUAL_IN and MANUAL_OUT oper…  and FX3 CPU to Parallel Port Socket DMA Operation-Manual Out/In

How to connect CPU to PPort in the Master/Slave example?

In the attachment in the above references, there is a GPIF designer project too, but GPIF setting has nothing to do with who will be connected to P Port, right? So can I just use existing GPIF designer projects for Master/Slave example and only modify the DMA initialization code in the Master/Slave firmware to swith one end of some DMA channel from U port to CPU port and keep another end as before?

There is mouse HID example in the SDK. Is there some reference about keyboard HID? External source is fine too.

Hi,

We are developping a board CYUSB3014(fx3) based connected to high data rate sensor. data Rate is typically beyond 1Gbps and is dedicated to medical applications.

Furthermore, for security reasons, the board is also connected (through I2C) to a data logger that delivers small (typically 16 to 32 bytes) packets to be included in high data rate flux at every packet. The change from the data logger is asynchronous from the high data rate flux but we have to send those data in flux.

For example :

High Data Packet 1 (~32 KB) < 32 bytes status #1 logger> High Data Packet 2 (~32 KB) < 32 bytes status #1 logger>  ...

High Data Packet 40 (~32 KB) < 32 bytes status #1 logger>High Data Packet 41 (~32 KB) < 32 bytes status #2 logger (new set)> ... etc.

with "manual_byte" operations mode, we retrieve the 32 KB packets from high data rate and add the logger's data before recommit. this is working, but the rythm is not that fast, less than expected.

we would like to daisy chain dma operations to use an auto_mode dma process where the "32 bytes signature" data would be located in memory and be automatically added to flux as above.

Would it be possible to proceed like in CyU3PDmaDscrChainCreate function but to create such a "flux" / "memory" / "flux" dma operation chain ?

Thank you for your help,
Best Regards,

Q1) We have tied MIPI_RESET to GND through a pull-down resistor and don’t have a way to drive this pin high (by design). We only control the input to the RESET# pin. So presumably we can ignore the requirement for MIPI_RESET# that is depicted in the timing diagram of the datasheet (Figure 4 on page 10 of document number 001-87516 Rev. *N)?

Q2) The attached PowerPoint slides depict the voltages in the timing diagram at power-up and power-down. I believe we comply with all the requirements in the timing diagram, but I am concerned about the fact that VUSB is not a monotonically rising signal. Although VUSB starts to rise before all other voltages and quickly reaches 4V, it then drops down to around 2.5V. Eventually VUSB rises again to its steady state value of ~5V but this doesn’t happen until after the other voltages have reached steady state. Is this a cause for concern?

Thanks,

James