USB superspeed peripherals Forum Discussions

I could not find the above mentioned file neither in the Software Development kit nor at the Cypress site. Could you give me a download-link please ?

Kind regards

Pierre Hermans

Normally we use CyFx3BootUsbStart( CyTrue, ..) with option "Re-Enumeration will NOT be done" and it works as expected.

At the unusual situation where the device power up, start it's USB connect cycle, short after CyFx3BootUsbStart, CyFx3BootUsbConnect but before device became emumerated, a very short USB disconnect / re-connect occur. From this moment on, the device don't start it's enumeration cycle, firmware stay at bootloader and wait until USB connection is ready.

This behaviour can be easily reproduced within a debug session, by restarting the debug session directly after CyFx3BootUsbConnect have been called. From than till next device reset (power cycle or CyFx3BootDeviceReset), no USB enumeration will be triggered. Further firmware reloads within the debugger won't fix that.

If we call CyFx3BootUsbStart( CyFalse, ..)  with option "Re-Enumeration will be done" than it seems to work in any situation.

Is there a way to reset the USB within Second Stage Bootloader to ensure the same behavior like after first power up? Any thing to undo the changes cause by CyFx3BootUsbStart - option "Re-Enumeration will NOT be done"?

I have a callback registered with CyU3PUsbRegisterSetupCallback and I am not using fast enumeration.

Currently I am using the callback to log setup transactions.

Comparing my log with that from a USB analyzer I can see that I get most SETUP transactions with the exception of SetAddress.

Is it possible for the application to be notified when a SetAddress transaction has occurred?

Hi All,

I have been working on this firmware (https://community.cypress.com/thread/16971?start=0&tstart=0) and have finally run out of memory?  When I compile my latest code, the linker spits out:

c:/program files (x86)/cypress/ez-usb fx3 sdk/1.3/arm gcc/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld.exe: OV5647_dual_camera_NOUVC_e.elf section `i._tx_mutex_prioritize' will not fit in region `SYS_MEM'

c:/program files (x86)/cypress/ez-usb fx3 sdk/1.3/arm gcc/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld.exe: section .data loaded at [40030000,4003188f] overlaps section i._tx_mutex_prioritize loaded at [4002ff00,400300ff]

c:/program files (x86)/cypress/ez-usb fx3 sdk/1.3/arm gcc/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld.exe: section i._tx_queue_cleanup loaded at [40030100,400301b7] overlaps section .data loaded at [40030000,4003188f]

c:/program files (x86)/cypress/ez-usb fx3 sdk/1.3/arm gcc/bin/../lib/gcc/arm-none-eabi/4.8.1/../../../../arm-none-eabi/bin/ld.exe: region `SYS_MEM' overflowed by 440 bytes

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\ARM GCC\/arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':

writer.c:(.text+0x20): undefined reference to `_write'

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\ARM GCC\/arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':

closer.c:(.text+0x18): undefined reference to `_close'

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\ARM GCC\/arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':

lseekr.c:(.text+0x20): undefined reference to `_lseek'

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\ARM GCC\/arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':

readr.c:(.text+0x20): undefined reference to `_read'

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\ARM GCC\/arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':

sbrkr.c:(.text+0x18): undefined reference to `_sbrk'

collect2.exe: error: ld returned 1 exit status

cs-make: *** [OV5647_dual_camera_NOUVC_e.elf] Error 1

13:08:43 Build Finished (took 13s.977ms)

The linker map files are pretty confusing to look at so I have written a little program to summarize lengths of the various modules.  When I look at the current version of my code, and a former version that does compile without error, I see the current version is *shorter* than the old version that compiles, which is perplexing.  This brings up numerous questions:

1) Can someone point me to a document that discusses the various memory sections used by the CX3 libraries?

2) The CX3 (CYUSB3064) part data sheet says the parts have 512 or 256 KB of SRAM but there is no mention as to which family member has how much memory.  Are we to guess that the 4-lane version has 512K and the 2-lane as 256K?

3) Neither program is anywhere near close to this limit, is SYS_MEM some special memory section that must be considered separately, or am I not understanding how data is loaded for CX3 execution?

4) I have seen the compiler spit out similar errors when I had a grave macro syntax problem.  I had imbalanced parenthesis in a macro and compensated for it by adding an extra parenthesis in the macro expansion.  The compiler didn't mention and memory overlaps, but did spit out many missing symbol errors (_sbrk, _write, _close, ...).

Thanks as always,

Scott

Hello FX3 gurus,

We want to take uncompressed video streams from Sony's IMX253 CMOS sensor and transfer them to the PC by the help of FX3 module. The best we can take from IMX253 sensor is UHD image of 4096 x 300 pixels in size. We have FPGA device as a bridge between IMX253 and FX3 module. FPGA is used to apply demosaicing, noise reduction, color/gamma correction algorithms. What we have at the output of all those blocks are pixels in RGB space with 12-bits resolution per pixel (or 10-bits resolution per pixel if we don't have enough FPGA resources). 

I found that AN75779 application note could be the perfect place to start with. Given the fact that we want to take the maximum we can from FX3 module, our Databus is 32-bit wide. Consequently, I created a new project in GPIF II Designer by following AN75779 document in order to generate appropriate cyfxgpif2config.h header file. Basically, I changed the width of the Databus and limit value of LD_ADDR_COUNT and LD_DATA_COUNT counters to 4091.

Here is what I did on the FX3 firmware side (SDK 1.3.4 is used, by the way):

In uvc.c file:

I also changed the info about bit depth, image size, frame size and frame rate of the Super Speed Configuration descriptor in cyfxuvcdscr.c file:

I did not touch Min bit rate bits/s field and I leaved streaming encoding format to YUY2 for the moment.

Is there anything we are missing to change? I did not change the descriptor fields of the High Speed Configuration descriptor because we are mainly interested in USB 3.0 transfers.

We would like to use some open-source video players (e.g. VLC, VirtualDub...) to try playing our streams on PC side. Consequently, we should transfer them some of the streaming encoding formats they are supporting. It would be the most appropriate for us to send uncompressed streams in RGB format but I've been reading that sending the stream in RGB format is not supported by those open-source video players. Can you confirm this?

Is there any other streaming encoding format in addition to YUY2 that is supported by open-source video players? How about YCbCr?

Thank you very much for your time and effort. It is really appreciated.

Sincerely,

Bojan.

Hi

My project we are using the cypress FX3s dongle board. I need to increase the speed of SD card writing & Reading using (FATFS),

Currently my project coping speed is taking around  69 seconds for 1 Gb file ,I want to be reduce to 55 second .

so I am planning to use ping pong buffer method to increase the copy speed .

MY project overall view

Currently three threads I configured

thread1 - Read the data from the SD card & Writing into the Second SD Card (this thread I m planning split in to two thread one for write another one for read)

thread2 - using for the USB UART

thread3 - using for USB Mass Storage

Thread3 will be Suspended when thread1 execution.

when first thread reading data from SD card using DMA, the handle is given to the DMA that time I plan to switch to another thread for writing, but it’s not switching without Thread sleep function if I use thread sleep function, my copying time is increased Actually I want, two thread to be act as a parallel operation then may be I can increase the speed please provide me your valuable suggestion

Best Regards

K Manikandan

I am trying to use FX3 in Slave FIFO interface. I am using code from an example provided with AN65974.

The only difference to the example is that I tried to do it using single transfer with Burst set to 0 as follows:.

#else //16

    CyU3PGpifSocketConfigure (0,CY_U3P_PIB_SOCKET_0,3,CyFalse,0);

    CyU3PGpifSocketConfigure (3,CY_U3P_PIB_SOCKET_3,3,CyFalse,0);

#endif

Only flaga (DMA_RDY) is used.

I am sending a sequence of increasing numbers to check if it works .

It appears that one word (16 bit) is always missing each time after next 1024 bytes are transferred. It looks like this:

(at address 400h: word B1 5D is missing)

Here is FPGA state machine for a single transfer.

The fifo_emprty flag is not used.

Hi

Have you scheduled a release date for the next FX3 SDK (> 1.3.4) ?

Do you have a bug list of the current FX3 SDK?

Hello

I’m using the FX3 for transferring data from a FPGA to PC, and having a problem emptying the last partly filled buffer after the acquisition has finished.

On the FPGA side the design is based on the Slave FIFO interface described in AN65974.

The software on the PC is based on Streamer application modified to store the received data to a file. Like in the streamer I use the API methods for asynchronous IO (BeginDataXfer, WaitForXfer, and FinishDataXfer) and a circular FIFO of buffers (queue).

During steady state the FIFO mechanism works great with the data transferred as expected.

The acquisition stops when the FPGA stops sending data and WaitForXfer reaches timeout. At this point there is one partly filled buffer in the memory which I am having difficulties emptying.

I would like to determine how much data was written to this last buffer. If I understand the API correctly, running the FinishDataXfer method on the buffer, i.e. FinishDataXfer(buf_fpga, cur_len,…), should set the actual number of bytes transferred in the cur_len field. But in practice calling FinishDataXfer always sets cur_len to 0.

What am I missing here?

What exactly is the right behavior I should expect from FinishDataXfer?

Is there a way to determine the number of bytes transferred without calling FinishDataXfer?

Attached below is the relevant section of my code.

Thanks for the help,

Oren