USB superspeed peripherals Forum Discussions

Hi all,

CyU3PUsbSendEp0Data has a race condition that can cause delays of 500ms per call, despite successful completion. I just wanted to discuss a work-around or a fix.

Scenario:

    
1. implement a control IN transfer that spans multiple USB Control Endpoint packets (e.g. 2048kB)
    
2. the firmware shall respond in chunks of MaxPacketSize (e.g. USB-3.0 super-speed connection: 512 Bytes; else 64 Bytes)
   

As per SDK API documentation of CyU3PUsbSendEp0Data(), this is an acceptable implementation: cyu3usb.h states "Multiple calls of this function can be made to respond to a single control request as long as each call sends an integral number of full packets to the host."

Recently, we noticed that this sometimes leads to long-lasting transfers, that often even hit the time-out of the host applications DeviceIoControl calls. For example, it happens using a Intel(R) 6 Series/C200 USB Enhanced Host Controller (USB-2.0 high-speed).

A work-around seems to be increasing chunk size, i.e. using 512 Bytes per call even for USB-2 connections. But how can I know, how much margin it provides?

The problem can be traced down to a race condition. In CyU3PUsbSendEp0Data(), after CyU3PDmaChannelSendData the DMA socket state and Egress Endpoint Manager state are checked (with time-out of 500ms):

        while ((((UIB->sck[0].status & CY_U3P_UIB_STATE_MASK) >> CY_U3P_UIB_STATE_POS) != CY_U3P_UIB_STATE_ACTIVE) ||                 ((UIB->eepm_endpoint[0] & CY_U3P_UIB_EEPM_EP_READY) == 0))

Please find attached a modified version of the source code. It reports these status signals before and after the while-loop.

It can happen that socket state is already CY_U3P_UIB_STATE_STALL and the EEPM is not ready. This can be enforced by adding a small delay before "while" (also contained in the attached source file). This condition seems to tell that the transfer has already completed.

Obviously, the while-loop can be improved. My proposed solution would be adding the following lines to the loop body:

    if ((((UIB->sck[0].status & CY_U3P_UIB_STATE_MASK) >> CY_U3P_UIB_STATE_POS) == CY_U3P_UIB_STATE_STALL)         && ((UIB->eepm_endpoint[0] & CY_U3P_UIB_EEPM_EP_READY) == 0))         break;

But is this safe? I maybe do not completely understand the meaning and side-effects of these flags.

Thanks

 I'm working with the FX3 SuperSpeed Explorer Kit to try and send data to (and receive data from) an FPGA. I'm new to wkring with USB controllers, and I'm not really a sofware engineer, so I looked at AN65974, and I found that the LOOPBACK example works with my needs with a few edits. Using their loopback mode, I tried to separated the read and write sequences so they operate independently from each other but in such a way that the loopback function can still occur.

Working with a 100 MHz clock coming from the FPGA, I am trying to perform a loopback operation. I feel if I can implement the separation of the processes correctly, I can loop the data back normally. However, when I perform the loopback sequence, the data I receive is not the data I sent out. I'm working with a USB 2.0 connection, since I don't have access to a USB 3.0 port, and I'm sending 512 B of data out at one time. I'm not sure whether it is a firmware problem, but this also occurs with the original project posted by Cypress with their firmware. Any suggestions on how to solve this?

If it helps, according to Cypress, when initialized, the flags should be: FLAG A = FLAG B = HIGH, FLAG C = FLAG D = LOW.

However, Flag D, which is configured to be a DMA watermark flag for a thread, is HIGH. Could this cause problems with transfer accuracy?

 Hi all,

I have a EZ-USB FX3 DVK, when I turned on the board with the USB Boot mode, I observed that the pin D2(I2S_SD) is toggling with around 400KHz. I need to know why this pin alone is toggling but other I2S pins are at Low state. (I did not loaded the FX3 any Firmwares, FX3 USB Bootloader firmware residing in the BootROM only loaded).

Please help me, If there is any settings to make this pin to be at low during startup. Or is it possible to change the BootROM present in the FX3 ROM.

Thanks,

KCNGP

Hello everyone,

We are designing an application to add SDCard boot support for the Cypress CyUSB301X chipset through a SPI bus (bitbang mode right now for simplicity). The idea behind this is to:

1. boot in USB mode (PMODE to USB)

2. upload a 2nd bootloader image at address 0x40087000

3. jump to the 2nd bootloader

4. read an application firmware (elf2bin) from the SDCard and copy it into RAM

5. jump to the application firmware

Right now, we are stuck at step five. The RAM content seems coherent with the application firmware disassembly code (see below). The application firmware, in standalone mode, only toggle the LED2 pin every seconds and works fine. The 2nd bootloader code by itself works flawlessly also until it reaches the last line:

  CyFx3BootJumpToProgramEntry(address);

GDB tells us that we are now in an undefined interrupt UndefinedISR (see below).

In the Cypress examples, it seems that no specific actions must be done before using the CyFx3BootJumpToProgramEntry() function however, there is obviously something wrong with our code.

Have you ever experienced problem with the CyFx3BootJumpToProgramEntry() function or with jump between 2nd bootloader and application in your designs ?

Best regards,

Christophe

 #
# GDB trace
#
Transfer rate: 4 KB/sec, 338 bytes/write.
(arm-gdb)c
Continuing.

Breakpoint 1, main () at main.c:99
99              ioCfg.isDQ32Bit = CyFalse;
(arm-gdb)n
100         ioCfg.useUart   = CyFalse;
(arm-gdb)n
n101        ioCfg.useI2C    = CyFalse;
(arm-gdb)n
102         ioCfg.useI2S    = CyFalse;
(arm-gdb)n
103         ioCfg.useSpi    = CyFalse;
(arm-gdb)
104         ioCfg.gpioSimpleEn[0] = 0;
(arm-gdb)
105         ioCfg.gpioSimpleEn[1] = 0;
(arm-gdb)
106         status = CyFx3BootDeviceConfigureIOMatrix (&ioCfg);
(arm-gdb)
107             if (status != CY_FX3_BOOT_SUCCESS)
(arm-gdb)
110             CyFxPrint("Jump to entry point: %08x\n\n", fwChunk.dAddr);
(arm-gdb)
112         asm("b 0x40006fa0");
(arm-gdb)

^C
Program received signal SIGINT, Interrupt.
UndefinedISR () at cyfx_armcc_startup.S:80
80      cyfx_armcc_startup.S: No such file or directory.
(arm-gdb)x /100x 0x40006fa0
0x40006fa0:     0xe59f1034      0xe3e00000      0xe5810000      0xe59f102c
0x40006fb0:     0xe2411008      0xe3a02a01      0xe3a000d3      0xe121f000
0x40006fc0:     0xe0811002      0xe3c11007      0xe1a0d001      0xebffff7c
0x40006fd0:     0xeb00042e      0xebffffc2      0xeafff009      0xfffff014
0x40006fe0:     0x40001000      0xe92d4010      0xe1a04000      0xe3540000
0x40006ff0:     0x1a000001      0xe3a00041      0xe8bd8010      0xe1a00004
0x40007000:     0xeb001eda      0xe3500000      0x1a000001      0xe3a00040
0x40007010:     0xeafffff8      0xe3a00000      0xeafffff6      0xe92d4010
0x40007020:     0xe1a04000      0xe3a01000      0xe1a00004      0xeb001f34
0x40007030:     0xe8bd8010      0xe92d4010      0xe1a04000      0xe3a01001
0x40007040:     0xe1a00004      0xeb001f2e      0xe8bd8010      0xe1a01000
0x40007050:     0xe351003d      0xaa000001      0xe3a00001      0xe12fff1e
0x40007060:     0xe3a00000      0xeafffffc      0xe92d4070      0xe1a04000
0x40007070:     0xe3a05000      0xe3540000      0x0a00000a      0xe3540001
0x40007080:     0x0a000004      0xe3540002      0x0a00000e      0xe3540003
0x40007090:     0x1a000010      0xea000007      0xe1a00000      0xeb001f2c
0x400070a0:     0xe1a05000      0xea00000d      0xe1a00000      0xeb001f24
0x400070b0:     0xe1a05000      0xea000009      0xe1a00000      0xeb001f2c
0x400070c0:     0xe1a05000      0xea000005      0xe1a00000      0xeb001f24
0x400070d0:     0xe1a05000      0xea000001      0xe1a00000      0xe1a00000
0x400070e0:     0xe1a00000      0xe1a00005      0xe8bd8070      0xe92d4070
0x400070f0:     0xe1a04000      0xe3a05000      0xe5d40000      0xe3500002
0x40007100:     0xba000002      0xe5d40000      0xe3500010      0xda000001
0x40007110:     0xe3a00040      0xe8bd8070      0xe5d40001      0xe3500000
0x40007120:     0x1a000004      0xe5940004      0xe3500000      0x0a000009
(arm-gdb)

#
# Disassembly
#
40006f94:   e3c11007    bic r1, r1, #7
40006f98:   e1a0d001    mov sp, r1
40006f9c:   e12fff1e    bx  lr

40006fa0 <CyU3PFirmwareEntry>:
40006fa0:   e59f1034    ldr r1, [pc, #52]   ; 40006fdc <CyU3PFirmwareEntry+0x3c>
40006fa4:   e3e00000    mvn r0, #0
40006fa8:   e5810000    str r0, [r1]
40006fac:   e59f102c    ldr r1, [pc, #44]   ; 40006fe0 <CyU3PFirmwareEntry+0x40>
40006fb0:   e2411008    sub r1, r1, #8
40006fb4:   e3a02a01    mov r2, #4096   ; 0x1000
40006fb8:   e3a000d3    mov r0, #211    ; 0xd3
40006fbc:   e121f000    msr CPSR_c, r0
40006fc0:   e0811002    add r1, r1, r2
40006fc4:   e3c11007    bic r1, r1, #7
40006fc8:   e1a0d001    mov sp, r1
40006fcc:   ebffff7c    bl  40006dc4 <CyU3PSysSetupMMU>
40006fd0:   eb00042e    bl  40008090 <CyU3PSysCheckBootState>
40006fd4:   ebffffc2    bl  40006ee4 <CyU3PSetupStackPtrs>
40006fd8:   eafff009    b   40003004 <CyU3PToolChainInit>
40006fdc:   fffff014            ; <UNDEFINED> instruction: 0xfffff014
40006fe0:   40001000    andmi   r1, r0, r0

Disassembly of section i.CyU3PDeviceConfigureIOMatrix:

40006fe4 <CyU3PDeviceConfigureIOMatrix>:
40006fe4:   e92d4010    push    {r4, lr}
40006fe8:   e1a04000    mov r4, r0
 

 Hello,

I am writing software that deals with a device that's under development. The device collects data for a period of time, which is programmable, and sends the result as a block of 64k bytes to the PC via FX3. I receive the block through a CCyUSBDevice's BulkInEndPt by calling XferData(). I am finding that if I choose a timeout value short enough for the function to fail (because the data is yet to arrive) that it sometimes never succeeds on subsequent calls. Effectively, the data is lost. If I sit in a loop calling XferData(), the probability of losing the data increases as the timeout value I choose gets shorter. If I don't call it until after the data should have arrived, it never fails. Is this known behaviour of XferData(), or is the problem likely to be in the device? If it's the device, can anyone suggest a likely cause? (I am not a hardware person, but I can pass on responses to the device's designer.)

Regards

Hi,

Would anyone recommend a  USB3 Protocol Analyser for debugging the SuperSpeed bus. I've seen analysers from TotalPhase and LeCroy but its hard to know if these are a sutiable. I've used a USB 2 analyser in the past and this was very helpful in identifying and solving problems.

Thanks,

Sodfarl

 Hi,

I'm working with the FX3 DVK, following the application notes AN65974 to perform stream_in, stream_out and loopback transfer with my Xilinx FPGA. When performing stream_in and stream_out transfer, it seems quite ok.

However, during loopback transfer, after transfer data out, when I was trying to read data back from bulk in endpoint, it shows that zero length data transfered. I tried to capture how each control signal data react from FPGA side during transfer. I found that sfter SLOE# and SLRD# were both asserted, no data came out from FX3, my FPGA did not recieve any data, flagc and flagd remained 1.

How can I solve this problem?

Regards,

Zoe

Hi,

I'm working with the FX3 DVK, following the application notes AN65974 to perform stream_in, stream_out and loopback transfer with my Xilinx FPGA. When performing stream_in and stream_out transfer, it seems quite ok.

However, during loopback transfer, after transfer data out, when I was trying to read data back from bulk in endpoint, it shows that zero length data transfered. I think the communication betwwen FX3 and FPGA failed. So I tried to capture how each control signal data react from FPGA side during transfer. I found that my flagd is always 1 and never changed to 0 and my flagc once changed from 0 to 1, never changed back to 0. As a result, SLRD# keeps asserted during the whole process. Btw, I used the firmware code provided by Cypress and the flag configuration is just same.

How can I solve this problem?

Regards,

Zoe