- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
we have been monitoring CX3 value of its state machine in our firmware.
for this usage , we use CyU3PGpifGetSMState(&SMState); function from api.
Some SMState value are outside the 0-15 range. We have 131 and 132 values as SMState : is this normal ?
Thank you for your help,
Best Regards,
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This is because of the presence of mirror states in the CX3 state machine. Please refer section 4.5.1 " Mirror states" of gpif2_designer_userguide for more details about mirror states.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you please post the snippet where exactly you have called CyU3PGpifGetSMState API in your code?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi srdr,
thank you for this document and precision.
I'd like to precise some point on CX3 :
We can have data flux streaming during hours correctly at more the 1 Gbit/s typical. However, sometimes we observed a 0xC0000001 IRP return from camera in driver and streaming is stopped (no more answer on video endpoint because no more answer from CX3). Have you a code snippet for firmware after this particular situation ? others endpoints such are EP0 are answering correctly.
We have also sometimes another issue, related to previous one. After stopping flux completly because of previous issue, we restart and then frames are corrupted as if the dma buffers run with bad socket : Is there a way to reset socket and buffers of CX3 between two frames to restart always on same socket and a way to "clean" all buffers (producers+consumer) between two frames after all dma+Usb transfers are done (and of course before new data incoming from sensor) ?
Thank you for your help,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lebrun,
Can you please check the section IV USB Data Corruption (Page #8) in FX3_SDK_TroubleShooting_Guide.PDF (attached for reference) and implement the work around?
Refer GpifToUsb example firmware for the implementation.
Put a flag in USBEP_SS_RESET_EVT and print it in the infinite for loop.
I am trying to know whether there is SS_RESET_EVT in your case. If yes, we can reset the endpioints and DMA channel over a Clear Feature request.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi srdr,
this implementation doesn't change the behavior : it is never triggered so I guess this mean the usb 3 signal is rather correct.
Here is the situation : for some reason it happens that there is no more transfers because consumer socket is stuck whereas producer is present but of course buffers are very quickly full.
Is there a way to clean correctly all buffers from producer and consumer point of view so that transfers can happen again without stopping from driver ?
I think the problem is really in firmware part because I see the IRP request from driver that is not satisfied and no other transfer after that is satisfied.
Again this is quite rare but painful. For example, streaming @ 1.7 Gbits/s all week-end with no error.
Best Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi srdr,
I've tried everything to restart flux when driver receives an 0xC0000001 answer (and nothing else after) from CX3 to an IRP. We have a 4 producer buffers configuration (2 sockets, 2 buffers each). Each time we aren't able to restart consumer socket correct handling and the only way is to stop/restart flux from driver side which is not a correct solution.
In firmware, we are detecting correctly the situation after few ms. We are trying to reset the sockets to restart flux but if this seems to work for producer sockets this never works for consumer socket : what can prevent the consumer to restart on firmware side ?
Thank you for your help.
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi srdr,
I also have implemented the usb log debug feature. When streaming normal, I've got no message at all.
Once it is stalled i have :
DEBUG LOG : AF
DEBUG LOG : AF
DEBUG LOG : AB
DEBUG LOG : AB
Hope this can help.
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I confirm the debug log behavior.
Each time streaming is stopped, I've got these messages.
Sometimes there is only one DEBUG LOG : AF but always DEBUG LOG AF and then DEBUG LOG AB.
Is there a document to explain what this means exactly ?
Thank you for your help,
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The log 0xAF corresponds to CYU3P_USB_LOG_EP_UNDERRUN and 0xAB corresponds to CYU3P_USB_LOG_EPM_RESET.
EP underruns happen when the DMA channel is suddenly reset just when the PC asks for data. The USB controller will then receive conflicting information on buffer availability and an underrun is reported.
- Can you check if you do any DMA channel resets in your code (other than the clear_feature reset)? Also, do you see this underrun reported in USB 2 only or in USB 3 too?
- Can you please share your firmware?
In order to over come the Underrun error kindly follow the following code .
When you get a UNDERRUN in the call back , set a flag in the call back . In your main thread check for this flag and if the flag is set the reset the end point memory , DMA channel and starting the transfer again . The following line of code does the same .
CyU3PUsbSetEpNak(ep,1); // NAK the USB transfers until your endpoint memory is ready to recive
CyU3PDmaChannelReset(&gDmaCh); // Reset the DMA buffer to reset the pointer
CyU3PUsbGetEpSeqNum(ep,&seq); // Continue with the Old sequence number
CyU3PUsbResetEndpointMemories() // This API is used to reset reset and re-initialize the memory block, so that USB data transfers can resume.
CyU3PUsbSetEpSeqNum(ep,seq);
CyU3PDmaChannelSetXfer(&gDmaCht,0); // Start the transfer again
CyU3PUsbSetEpNak(ep,0); // Remove the NAK to start USB transfers again.
Let us know if you are still facing any issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
thank you for this information.
For the first point, I've logged with DebugPrint every dmareset places. It is not called while this condition is triggered.
I can send parts of firmware but not all.
I've included the flag detection while underrun comes. I include your code, check and tell the results.
thank you for your help,
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I confirm that firmware doesn't call dmaMultiChannelReset while streaming. By the way it is a multichannel many_to_one configuration, so I used the corresponding function ("multi") for SetXfer and channel reset.
But the issue is still present : the callback is triggered with an CY_U3P_USB_EVENT_EP_UNDERRUN event from endpoint 0x83 but the code doesn't "unblock" the situation : no transfer after.
Thank you for you help
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I forgot to tell that camera has a high data rate and is working on usb 3 port only.
For now the flag underrun is effectively set, the processing is done outside the callback function but consumer socket doesn't restart. From driver part, the driver receives nothing once underrun condition has been triggered.
I use your code with Multi in names tag for SetXfer et dma reset.
I also set a debug condition at each FrameValid : the message is correctly displayed after your snippet code has been ran, which means I guess that sensor is delivering data correctly and that producers sockets are ok.
Thank you for your help,
Best Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi keaj,
Here is some additionnal information about the current behavior.
we have a buffersize of 49152 bytes and PC driver is asking (16*49152) bytes at each IRP. So during frame transfer there are mostly C0000 (16*49152) transfers size + one transfer smaller due to wrapup functions at end of frame and because it is not possible to reach multiple of 49152 for a complete frame transfer size.
When overrun callback is triggered, the number of data transferred in last IRP packet (seen through an usb3 analyzer) is also a multiple of 49152 size. For example, at last transfer stop, the last packet has a size of 0x84000 bytes (11*49152) instead of 16*49152. For me this means the error comes from the fact there are no more data coming from gpif : thus it cannot restart through usb functions only ?
Is this correct and is there a way to confirm (and of course correct) this through gpif functions ?
I must say that I log the FV of sensor through a printout debug and even after the streaming is stopped, the FV printout is still present : so data seem to be still delivered by sensor when this issue is triggered.
Thank you for your help,
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
extra information :
we use a 24 bits GPIF and we a thread that monitors the mipi error. Mipi error are never present during normal streaming as well as "stopped" stream. Counter stays at 0.
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I still don't understand why the process is not restarting. I've included your code as you told me, check the result for each function. No error returned, everything is CY_U3P_SUCCESS but stream doesn't restart.
I've also tried to add a MipicsiReset (soft_reset) among your code but again, return code is success and nothing restarts after.
I've checked out through an analyzer that nothing is sent on usb after your code is executed whereas the FV are present.
So, it looks as if the data where not transferred anymore either from gpif to socket producer or from producer to consumer, I don't know.
Is there any way to check these possibilities ?
Thank you for your help,
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi keaj,
what is the status of CyU3PUsbEnableEPPrefetch function now with 1.3.4 sdk ? Could it be a solution for correcting the issue ?
Should I compile back to 1.3.3 to have this taken into account ?
Thank you for your help
Best Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I've tried to use CyU3PUsbEnableEPPrefetch to fix issue but it seems to have no effect. is this api function still relevant for 1.3.4 ? I read that it is not used anymore with this sdk version.
Best Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Have FlushEP or ResetEP a utility here ?
Again no change of behavior.
Best Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can try the following in your case.
Set a timer with an appropriate time period (based on your frame rate).
Start the timer in the application start (CyCx3AppStart).
Stop and Modify the timer in the producer event of DMA call back for a partial buffer and start it again.
The timer should be set to initial value if the timer does not expire.
If the timer expires, in the Timer callback, the CX3_DMA_RESET_EVENT event will be set.
In the CX3_DMA_RESET_EVENT, stop the application and start it again.
Please refer AN75779 example firmware for this implementation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi srdr,
thank you for this information, we'll try to proceed this way with AN75779 implementation.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
here is the snippet code form USBBulkSourceSink example.
best regards
void DisplayLog(void)
{
/* Compare the current USB driver log index against the previous value. */
if (gl_UsbLogBuffer == NULL)
return;
tmp1 = CyU3PUsbGetEventLogIndex ();
if (tmp1 != prevUsbLogIndex)
{
tmp2 = prevUsbLogIndex;
while (tmp2 != tmp1)
{
CyU3PDebugPrint (4, "DEBUG LOG: %x\r\n", gl_UsbLogBuffer[tmp2]);
tmp2++;
if (tmp2 == CYFX_USBLOG_SIZE)
tmp2 = 0;
}
}
/* Store the current log index. */
prevUsbLogIndex = tmp1;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
This is because of the presence of mirror states in the CX3 state machine. Please refer section 4.5.1 " Mirror states" of gpif2_designer_userguide for more details about mirror states.