USB superspeed peripherals Forum Discussions
I've been "exploring" the FX3 with the superspeed explorer kit. Pretty sweet so far, but I can't for the life of me figure out how to get it to run in a raw packet mode. AKA I simply want a mode where it forwards link layer packets that don't have errors to RAM independent of their endpoints/etc.
Any hints if this is possible, or how to achieve it?
Of course I would like the opposite as well, a way to send a user defined packet back out on the superspeed bus.
Thanks,
Show Lesshello, i use cyusb3014, streamer c#, usb3.0
i have good speed and no failure packets.
but when i connect usb-flash, streamer print all failure packets, and need reset device.
Show LessHello
I wrote post about SD clk several day ago (http://www.cypress.com/?app=forum&id=167&rID=110967)
I head something of the thread, but I still can't solve it.
I tested two class of SD card made by Transcend. for one ting is Class 10, for another thing is UHS-1(x300)
I set a gpio for working 1.8v on the board. there are two SD card is not working.
SD clk works only 400Khz.
but I tested another SD card made by SAMSUNG. the sd card is working on the 1.8V
so I tested SDR mode and DDR mode. but SD clk working 50.4 Mhz Fixed.
This is result of the test.
VIO2/VIO3 is 3.3V, DDR mode: 14MB/s read. The clk works 50.4 Mhz.
VIO2/VIO3 is 3.3V, SDR mode: 14MB/s read. The clk works 50.4 Mhz.
VIO2/VIO3 is 1.8V, DDR mode: 14MB/s read. The clk works 50.4 Mhz.
VIO2/VIO3 is 1.8V, SDR mode: 14MB/s read. The clk works 50.4 Mhz.
The result is no changed to change Voltage or SDR/DDR mode.
What I miss it ???
Thank you
Regards.
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:
- implement a control IN transfer that spans multiple USB Control Endpoint packets (e.g. 2048kB)
- 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
Show LessI'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?
Show LessHi 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
Show LessHello
I need DSN file for FX3s FPGA Dev Board like "FX3_Validation_board.pdf" in FX3 Software Development Kit.
But I can't find the file in CYPRESS or PACTRON web site.
Can I get the file??
Thank you
Regards.
Show LessHello 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
Show LessHello
I use FX3s eveluation board to study USB 3.0 spec, But I have some wonder about descriptors.
I think kind of ordering problem, but I can't understanding cleary.
USB 3.0 Specification Release Number for example, in Device descriptor. the Number is 0x0300 but in the example code(USBBulkLoopAutoEnum Descriptor) is written 0x0003.
another sample is Vendor ID, I know Cypress Semiconductor Vendor ID is 0x04B4, but example code served 0xB404.
By ther way, Product ID is different, CY30700 Licorice evaluation board product number is 0xF000, example coude served 0xF000.
What is different thing about Product ID and Vendor ID or Specification Release Number ??
Redards.
Show Less