CX3 UVC ubuntu 18.04 uvcvideo: Non-zero status (-71) in video completion handler

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MaKe_3881991
Level 1
Level 1
Welcome! First question asked First reply posted

Hello,

I have a CYUSB3065 based design. The firmware is based on an example:

FX3_SDK_1.3.4_Linux/cyfx3sdk/firmware/cx3_examples/cycx3_uvc_ov5640/

All I did is changed the resolution in USB descriptors and replaced the functions related to the image sensor.

For testing, I compiled a simple example of how to grab an image from the USB camera found at:

Simple C++ program to capture a webcam frame in Linux · GitHub

The trick is that every second time I receive 0 bytes from the CX3 and the following error is generated to the kernel log:

uvcvideo: Non-zero status (-71) in video completion handler.

I used Wireshark to monitor the USB traffic and noticed that the camera indeed reports the error. I have several development boards with the same sensor (including Tania dev. board) I use and all these boards behave the same: getting single frame fails every second time, resulting in -71 error code in the kernel log.

I think the fw lib generates the error reply in CX3 somewhere "deep inside" as no callback functions are called. DMA starts running, but the host just closes the connection as the result of the error message. I attach the Wireshark log. I have the impression that host does everything right but CX3 just fails every second time. Any comments, suggestions?

BR, Madis

0 Likes
1 Solution

Hello Madis,

The reason for -71 is documented here Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830 .

Please confirm whether the host application is sending Clear feature request after you close the video grabbing. If there is no clear feature request to stop the data transfer from GPIF II USB, you will see -71 error.

As you know BULK guarantee the delivery and ISOC does not guarantee the delivery. If you are fine with it, you can go ahead with ISOC.

Regards,

Sridhar

View solution in original post

0 Likes
8 Replies
KandlaguntaR_36
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

Hello Madis,

Is the host application working fine with Cypress development board with default firmware?

In the modified firmware, have you changed the probe control settings along with USB descriptors, MIPI and Image sensor funtions?

Regards,

Sridhar

0 Likes

Hello,

the host application does the same for me for Tania board with original FW (CX3_ISP_MergedFirmware_1.22_0.31.img).

For the custom firmware, yes, I modified the USB descriptors and functions related to the image sensor. I used ov5640 based sample project and modified it for Sony (same as Tania rear camera). But my modified FW behaves the same, every second single frame grab fails.

It's worth noticing that I can grab as many frames as needed in case I do not close the camera in between. The problem only occurs if I do the sequence "open->grab->close" for every frame... It should work like this, I guess.

Additionally, the process does not fail if I reload uvcvideo module in between every grab.

The mystery is: why cypress is reporting error for host every second time (see the Wireshark capture). The debug prints from my custom FW show that the app is started, as supposed to be, DMA is started, but error is reported by cypress FW before DMA manages to complete the frame...

BR, Madis

0 Likes

Hello,

I just tested the original project:

FX3_SDK_1.3.4_Linux/cyfx3sdk/firmware/cx3_examples/cycx3_uvc_ov5640/

with the Denebola dev. board. The behavior is the same, every second frame grab fails. Any ideas, comments?

BR, Madis

0 Likes

Hello Madis,

Please confirm whether the host application working fine with any Non-Cypress UVC devices (like in-built PC camera)?

Regards,

Sridhar

0 Likes

Hello,

yes, other cameras (random webcams, including Logitech 4K model we purchased for testing) work fine.

I managed to get rid of this -71 error after changing the video stream endpoint type from BULK to ISO. I used the sample from:

CX3 Isochronous mode

It is possible to use the above mentioned sample both in ISO and BULK mode. BULK generates -71 as every other sample I found, ISO does not. And as this ISO endpoint behaves better for us (we have many cameras connected) I stick with it.

BR, Madis

0 Likes

Hello Madis,

The reason for -71 is documented here Invalid Sequence Error in Multi-Channel Commit Buffer - KBA218830 .

Please confirm whether the host application is sending Clear feature request after you close the video grabbing. If there is no clear feature request to stop the data transfer from GPIF II USB, you will see -71 error.

As you know BULK guarantee the delivery and ISOC does not guarantee the delivery. If you are fine with it, you can go ahead with ISOC.

Regards,

Sridhar

0 Likes

Hello,

The strange thing is that I get that -71 every time I re-open the camera. The first frame is the one that fails. After the first frame, everything is back to normal. So I guess the endpoint is left in some strange state after the host app closes. So if anybode is facing the same issue, its worth digging the closing procedure.

Regarding the ISOC endpoint. Yes, Im aware that this type of transfer does no guarantee the delivery. But as I have 20M sensor connected, there is not enough memory anyway to perform retransmissions in case of link failure. So either the currnent data is lost in case of ISOC endpoint or the incoming data from the sensor is lost in case of no free buffers due to retransmissions in BULK scheme. In addition, as ISOC is guaranteed bandwith, it tends to behave better in case of multiple cameras.

So I stay with ISOC. Thank you for your support!

BR, Madis

0 Likes

>> The strange thing is that I get that -71 every time I re-open the camera. The first frame is the one that fails. After the first frame, everything is back to normal. So I guess the endpoint is left in some strange state after the host app closes. So if anybode is facing the same issue, its worth digging the closing procedure.

When the host app closes, please check whether you are receiving the clear feature request, which aborts the video streaming in FX3.

You may refer CyFxUvcApplnStop fucntion in AN75779 example firmware. Here we are flushing the Endpoints and Resetting the DMA channel. Hence there should not be any data in the endpoint.

Regards,

Sridhar

0 Likes