USB superspeed peripherals Forum Discussions

 Hi all,

 Do you have any idea to connect GPIF busses with different devices (Camera,EEPROM,FPGA) on the same time

Hello.

I want to exchange FX3 super speed to high speed at run time. but it fail. my code as below:

it is soming wrong or need do more? please help.

                apiRetStatus = CyU3PConnectState(CyFalse, CyFalse); //disconnect
                if (apiRetStatus != CY_U3P_SUCCESS) {
                    CyU3PDebugPrint (4, "USB disconnect failed, Error code = %d\r\n", apiRetStatus);
                }

                CyU3PThreadSleep (10);

                apiRetStatus = CyU3PConnectState(CyTrue, CyFalse); //connect with High speed
                if (apiRetStatus != CY_U3P_SUCCESS) {
                    CyU3PDebugPrint (4, "USB Connect failed, Error code = %d\r\n", apiRetStatus);
                }

How to use the complete DMA buffer area?

I like to know how to use the complete DMA buffer area (of where the unallocatable part is going)

When using the default fx3.ld linker script, I can allocate a maximum of 13 x 16Kb Dma buffers with CyU3PDmaChannelCreate, any requests for more buffer will fail.

When reading the fx3.ld and the FX3 Memory Map section of the programmers manual, I come to the conclusion there is 256Kb available for dma buffers. So where is the remaining 3 x 16Kb?

The default memory map used for FX3 applications is as follows:

   Descriptor area Base: 0x40000000 Size: 12KB
   Code area       Base: 0x40003000 Size: 180KB   
   Data area       Base: 0x40030000 Size: 32KB    
  
   Driver heap     Base: 0x40038000 Size: 32KB  (0x8000)  (Update cyfxtx.c to change this.)
   Buffer area     Base: 0x40040000 Size: 256KB (0x40000) (Update cyfxtx.c to change this.)
  

I also adapted the fx3.ld and cyFxTx.c to change the allocatable DMA buffer area to 336Kb.
When I use these settings, I manage to allocate 18*16Kb Dma buffers with CyU3PDmaChannelCreate (in my application this is a buffer of 1.6ms)

I expect to get 21 x 16KByte buffers. So again I am missing 3 x 16Kbyte...

Adapted CyFxtc.c (set USE_CUSTOMLD compile flag to use)
----------------
#ifdef USE_CUSTOMLD
#define CY_U3P_MEM_HEAP_BASE         ((uint8_t *)0x40024000)   // custom. Must match fx3.ld in current dir
#else
#define CY_U3P_MEM_HEAP_BASE         ((uint8_t *)0x40038000)
#endif

Adapted fx3.ld
---------------
   /*
   Descriptor area Base: 0x40000000 Size: 12KB    
   Code area       Base: 0x40003000 Size: Reduced to 116KB (0x1D000)
   Data area       Base: 0x40020000 Size: Reduced to 16KB (0x04000)
  
   Driver heap     Base: 0x40024000 Size: 32KB  (0x8000) (Update cyfxtx.c to change this.)
   Buffer area     Base: 0x4002C000 Size: 336KB (0x54000)  (Update cyfxtx.c to change this.)
   */  
  
   ...
  
 SYS_MEM  : ORIGIN = 0x40003000 LENGTH = 0x1D000  
 DATA  : ORIGIN = 0x40020000 LENGTH = 0x4000  
 
Any suggestions?

OS: Centos 6.2
Kernel: 2.6.32
Controller: NEC Corporation uPD720200 USB3.0 controller

when using "libusb_bulk_transfer()" to get 16MB data from device (using 16 times, ask for 1MB at once), returned error code -99 (other error), use "dmesg" can found the following information:

usb 7-1: usbfs: process 6833 (test) did not claim interface 0 before use
xhci_hcd 0000:01:00.0: ERROR no room on ep ring
usb 7-1: usbfs: usb_submit_urb returned -12

the strange is that when add a wait for 1s between each time,the function return success.

(on usb2.0 port, it can work well)
 

Hi,

to my knowledge, the only way to perform a cold reset on the FX3 - apart from pulling the switch - is by using an API call.

This requires the implementation of a vendor command within the firmware that in turn calls CyU3PDeviceReset(). However, this approach is not generic at all. It requires either particularly tailored upload code or manual intervention.

It would be extremely helpful if there was a Cypress defined vendor command that enabled a reset of the FX3 independent of the firmware running on the device.

Would you mind to implement this?

Best regards,

Markus

I have an AUTO DMA with the USB OUT as the producer and a p-port as the consumer. I want to send the received byte count to my application. I have setup a callback that triiggers on a producer event. I thought that I may be able to use the function CyU3PDmaChannelGetBuffer but in the user guide it says that it should not be used for AUTO mode. So is there a way to get the received byte count from the buffer?

Thanks

JOn

Hello,

we're working with a multi-channel manual-out dma on the FX3, but we noticed that wrapping up a 32 Kb buffer takes very long time (CyU3PDmaMultiChannelSetWrapUp takes 160 us while a single CyU3PDmaMultiChannelCommitBuffer takes about 10 - 20 us).

Is there a way to speed up the wrap up? Why does it take so much?

Thank you very much.

Gianni

 I have a design with a USB OUT sending data to a p-port consumer. Its in auto dma mode. I decided to add the PIB interrupt code from the Designing with the EZ-USB® FX3™ Slave FIFO Interface app note to check that there are no errors. When I ran the design I am getting CYU3P_PIB_ERR_THR0_RD_UNDERRUN errors. The thing is I am not using thread 0 as the consumer is on thread 3. Anyone know why this would occur?

Thanks

Jon

Hi,

I'm working on a composite device that includes a HID interface, which requires an 8 byte MPS (max packet size) interrupt IN endpoint to send data.  The problem is that, when the FX3 is running a super speed, it always sends out more data than the MPS.  Specifically, the DMA buffer minimum size is 16 bytes, so it sends 16 bytes, which causes a bus error (and the host controller resets the device).  The HID data payload is 16 bytes total, so one might think that just upping the MPS to 16 bytes would work, but the OS's generic HID driver is submitting two 8 byte URBs regardless of the MPS setting, which will then fail with a babble error.  This problem doesn't exist when the FX3 is running at high or full speed (using same DMA/buffer firmware code, the device sends in two 8 byte packets).  I also threw together a vendor specific (non-HID_ interrupt IN endpoint interface and replicated the problem at 8 bytes (16 bytes is OK since I have control and can submit a 16 byte URB).  In any case, AFAICT at this point, this is a bug in the FX3.  I haven't found any release notes listing this issue and I'm using the latest 1.2.3 SDK.

Is there any other way I can force an 8 byte packet at super speed or any other workaround for this problem?

Thanks,
Perry