USB superspeed peripherals Forum Discussions
Hi, I'm Jay.
I will use CYUSB301X IC. so I will check to be possible to connect my custom board.
I want to connect video data line. It consists of 14 bits or 24 bit video data, Vsync, Hsync and Pclock.
I think it is possible because I saw AN75779 application Note.
thank you.
Show LessHi,
We are using CX3 to get data from ToF image sensor (Sony IMX528) over USB to host PC,
we would like to get maximum possible frame rate, now, i can get the raw data from sensor via CX3,
but i am hitting a issue when i am trying to compose the raw data into a frame with streamer app, there is few pixel data will random missing,
ex, 640x480 resolution but only receive 640x479 or 640x478 ...
Because the sensor IMX528 setting of THS prepare is 95 (0x5f), but CX3 THS prepare max value seems to be limited under 89 as below pic via EZ USB IDE ?
how can i modify the THS prepare max value to over 89 ? Thanks ~
IMX528 settings :
Image format : RAW12
Resolusion: 640x480 30fps
MIPI 4 lanes
Show Less
Hi,
I'm working on a project that uses a GPIF II Interface (connected to an FPGA) and a USB peripheral. I'm using the slave FIFO example (slfifosync) which is already really well documented. The only big things we changed are the DMA Channels to be Auto instead of Manual, the size (4k bytes) of the DMA buffers, the number of DMA buffers (2 with U2P, 16 with P2U) and we added some commands in the main thread function and other places to handle control transfers (coming from USB). Everything is working fine here.
Now we are at a point where we want to add some headers/footers directly into the Cypress Chip (CyUSB3) to repackage our messages coming from USB. So we changed the U2P DMA channel to Manual to begin with and checked if the bypass of the Manual instead of Auto would work. We added the "prod" signal and the callback as it was already in the initial slave FIFO example. But now, it seems like some commands sent from USB are well received and well responded but some aren't. Since I have a P2U Auto and a U2P Manual in this example, I'm wondering if there's some problems that can occur or if I'm missing something with the interrupt priority with the main CPU thread and the GPIF II.
Thanks in advance,
Keven
Show LessHi,
I am sending serial data by GPIF in two thread ( Multiple Thread in GPIF II for DR_data )
I have 32-bit serial data on DQ15 and SOF on DQ13. I realized that sometimes there is 33 clock cycles( but should be 32 cycles) between two SOFs. one zero is added. so the system's data rate is decreased.
How can I remove it? It seems that it happens at the end of each DMA transfer.
Thanks
Hi,
I'm running a CYUSB3014 in a USB camera application, using code based on the app note AN75779.
The FX3 is configured with a manual many-one DMA which takes 16368-byte buffers from the GPIF block, appends a 16-byte header to them (to make a full 16kb) and then commits them to the USB buffers. To do this it uses the GPIF DMA Callback.
The callback code is as follows:
/*******************************************************************************
* Name: void Streaming_GpifToUsbDmaCallback ( CyU3PDmaChannel *chHandle,
* CyU3PDmaCbType_t type,
* CyU3PDmaCBInput_t *input )
* Inputs: CyU3PDmaChannel *chHandle - pointer to the DMA channel
* CyU3PDmaCbType_t type - reason for the callback
* CyU3PDmaCBInput_t *input - pointer to DMA data
* Return: None.
* Notes: Callback for the GPIF to USB DMA.
******************************************************************************/
void Streaming_GpifToUsbDmaCallback ( CyU3PDmaMultiChannel *chHandle,
CyU3PDmaCbType_t type,
CyU3PDmaCBInput_t *input )
{
CyU3PDmaBuffer_t dmaBuffer;
CyU3PReturnStatus_t status = CY_U3P_SUCCESS;
/* The DMA has encountered an error */
if (type == CY_U3P_DMA_CB_ERROR)
{
CyU3PDebugPrint (4, "\nHardware error in DMA\n");
}
/* Producer event notification - packet is ready to send */
if (type == CY_U3P_DMA_CB_PROD_EVENT && stream_state == STREAMING_ON)
{
status = CyU3PDmaMultiChannelGetBuffer (chHandle, &dmaBuffer, CYU3P_NO_WAIT);
if(status == CY_U3P_SUCCESS)
{
/* Don't know why this occurs... but it does! */
if(dmaBuffer.count == 0)
{
CyU3PDmaMultiChannelDiscardBuffer(chHandle);
return;
}
// GENERATE HEADER (excluded for clarity)
AddHeader(dmaBuffer.buffer - sizeof(header_t), header);
// Commit the full 16kb buffer to maximise USB 3.0 burst usage
status = CyU3PDmaMultiChannelCommitBuffer (chHandle, dmaBuffer.size, dmaBuffer.status);
if(status != CY_U3P_SUCCESS)
{
//Turn off the sensor and stop streaming
}
// Only occurs on an end of frame block
if(dmaBuffer.count != DMA_BUF_FULL)
{
//Collect some stats
}
}
else
{
CyU3PDebugPrint (4, "\nError in getting buffer\n");
}
}
}
The key lines are those between 25 and 43, everything after that is just tallying up some stats about frame numbers and some error checking.
If I remove lines 31 to 36 the streaming halts, but with lines 31 to 36 included I start to see missing data at the PC end, as if some FULL buffers have been discarded. To test my theory I set some breakpoints in this function and examined what was going on:
Here you can see a successful transaction, with the breakpoint triggered on line 40:
The CyU3PDmaCBInput_t input points to a buffer of length 16368 (as expected) and after the CyU3PDmaMultiChannelGetBuffer function call the dmaBuffer structure also points to a buffer at a different memory location of 16368-bytes. From this I assume the input buffer has been copied to a new location, which is pointed to by the dmaBuffer struct, which will then allow it to be successfully commited to the USB buffers for transfer to the PC? I'm not 100% sure on this theory of operations however, as you can see that the buffer pointer points to 2 different characters in each case, which makes me wonder which of these 2 buffers is the "actual" data. Maybe one of these buffers is the previous buffer to be committed in the streaming process? If anyone could shed light on this that'd be wonderful.
The following is an unsuccessful transaction, triggered by a breakpoint at line 34:
Here you can see the CyU3PDmaCBInput_t input still points to a buffer of length 16368 (as expected), but after the CyU3PDmaMultiChannelGetBuffer function call the dmaBuffer structure thinks it is of length 0, whilst still pointing to a buffer at a different memory location. This could be the buffer from the previous transaction (as hypothesised above), or it could be legitimate data and the "count" is just wrong? But either way I'm confused as to how the CyU3PDmaMultiChannelGetBuffer
function returns CY_U3P_SUCCESS from a get buffer call which returned no buffer.
For anyone still playing along, here is my DMA setup:
/* Create a DMA channel for the GPIF to USB transfer. */
CyU3PMemSet ((uint8_t *)&dmaCfg, 0, sizeof (dmaCfg));
dmaCfg.size = CY_FX_DMA_BUF_SIZE;
dmaCfg.count = CY_FX_DMA_BUF_COUNT;
dmaCfg.validSckCount = 2;
dmaCfg.prodSckId [0] = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_0;
dmaCfg.prodSckId [1] = (CyU3PDmaSocketId_t)CY_U3P_PIB_SOCKET_1;
dmaCfg.consSckId [0] = (CyU3PDmaSocketId_t)(CY_FX_EP_CONSUMER_SOCKET | CY_FX_EP_BULK_CONSUMER_SOCKET);
dmaCfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmaCfg.prodHeader = 16;
dmaCfg.prodFooter = 0;
dmaCfg.consHeader = 0;
/* Register a callback for a producer event, and a consumer event. */
dmaCfg.notification = CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT | CY_U3P_DMA_CB_ERROR;
/* Attach the callback function */
dmaCfg.cb = (CyU3PDmaMultiCallback_t)Streaming_GpifToUsbDmaCallback;
apiRetStatus = CyU3PDmaMultiChannelCreate (&DMA_consumer_channel_handle, CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE, &dmaCfg);
if (apiRetStatus != CY_U3P_SUCCESS)
{
CyU3PDebugPrint (4, "CyU3PDmaMultiChannelCreate failed, Error code = %d\n", apiRetStatus);
App_ErrorHandler(apiRetStatus);
}
Any thoughts would be greatly appreciated!
Show LessHello!
In the FX3 SDK 1.3.4, CY_U3P_USB_TARGET_MASK is defined as 0x03.
According to the USB 3.2 specification, section 9.3, table 9-3 "Format of Setup Data", the recipient ranges from 0 to 31.
Shouldn't CY_U3P_USB_TARGET_MASK be changed to 0x1F?
Regards,
Tobias
Show LessHi RashiV_61,
Now, I have requirement about add extra data to last uvc frame, offer the sensor's timestamp, exposure time/ gain get from sensor to host.
the step :
1, CyU3PDmaMultiChannelGetBuffer got data from sensor in callback
2, check if it's the last frame "DmaBuffer.count < ES_UVC_DATA_BUF_SIZE"
3, if yes, then pad extra information to “DmaBuffer.buffer+DmaBuffer.count”
status = CyU3PDmaMultiChannelCommitBuffer (chHandle, (DmaBuffer.count + 12 + 48), 0);
else
status = CyU3PDmaMultiChannelCommitBuffer (chHandle, (DmaBuffer.count + 12), 0);
as you know, DmaBuffer.count from CyU3PDmaMultiChannelGetBuffer has not contain the extra 48 bytes.
this is not a correct process, might corrupt the memory .
sensor trigger cx3, cx3 padding header, sent out.
I want to know, if there is a api for this case, can insert data to the video flow.
Show LessHello
Q1) Is there a legal problem if they modify and distribute a part (inf file) of the Cypress USB driver?
Also, Should they get permission from Cypress in advance?
Q2-2) Please tell me the procedure to get the signature of the device driver
Best Regards
Arai
Show LessHello!
I'm building a UVC device based on the FX3 SDK 1.3.4.
My firmware prints lots of debug output via UART and hangs after a while.
Using the debugger, I found that several threads seem to be waiting for the glDebugLock mutex:
Some thread owns the mutex, but it does not print any new output.
I checked the source code of CyU3PDebugPrint and noticed that there is no CyU3PMutexPut call before the first return:
CyU3PReturnStatus_t
CyU3PDebugPrint (
uint8_t priority,
char *message,
...)
{
...
CyU3PMutexGet (&glDebugLock, CYU3P_WAIT_FOREVER);
...
stat = CyU3PDmaChannelCommitBuffer (&glDebugChanHandle, limit, 0);
if (stat == CY_U3P_SUCCESS)
{
stat = CyU3PDmaChannelGetBuffer (&glDebugChanHandle, &glDebugBuf_p, glDbgTimeout);
}
if (stat != CY_U3P_SUCCESS)
{
CyU3PDebugChannelReset ();
return stat;
}
glDebugBufOffset = 0;
CyU3PMutexPut (&glDebugLock);
return CY_U3P_SUCCESS;
}
If the CyU3PDmaChannelCommitBuffer or the CyU3PDmaChannelGetBuffer call fails, the function will exit early and the glDebugLock mutex will not be unlocked. Any future call to CyU3PDebugPrint from a different thread will block indefinitely.
Is it actually intended to return early from that function? Other functions like CyU3PDebugLogFlush do not return after calling CyU3PDebugChannelReset.
Regards,
Tobias
Show Less