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

USB superspeed peripherals Forum Discussions

GrAU_4638336
Level 4
Level 4
25 replies posted 10 replies posted 10 sign-ins

Good day,

In previous posts (mentioned below), I was able to successfully add a CDC debug interface and have my image stream running with a RAW10 format.

CDC Debug interface:
Debug interface through USB for CX3 + Image sensor application

RAW10 Image stream:

Stream is not working: Custom board OV9782 / CYUSB3064

Since that, I have been working on enabling/disabling the debug interface for production purpose. Both seem to work as expected on my host (Windows)

Although I'm struggling to find a way to get the YUV pixels value before automatic reformat by Windows...

Any hints are welcome, but I'll most probably create another topic for this point.

Anyway! The question for this topic is the following.

I have my camera working as expected on Windows, including or not the CDC interface.
I have my UVC camera correctly recognise on my linux host as a UVC device without any explicit issue.

See report of sudo dmesg for UVC only firmware:

[  248.912645] usb 1-2.3: new high-speed USB device number 4 using tegra-xusb

[  248.936318] usb 1-2.3: New USB device found, idVendor=04b4, idProduct=00f3

[  248.936390] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[  248.936440] usb 1-2.3: Product: WestBridge

[  248.936484] usb 1-2.3: Manufacturer: Cypress

[  248.936529] usb 1-2.3: SerialNumber: 0000000004BE

[  310.382199] usb 1-2.3: USB disconnect, device number 4

[  310.605183] usb 1-2.3: new high-speed USB device number 5 using tegra-xusb

[  310.627643] usb 1-2.3: New USB device found, idVendor=04b4, idProduct=00c3

[  310.627661] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[  310.627674] usb 1-2.3: Product: CX3-UVC

[  310.627685] usb 1-2.3: Manufacturer: Cypress

[  310.698215] uvcvideo: Found UVC 1.10 device CX3-UVC (04b4:00c3)

[  310.700264] uvcvideo 1-2.3:1.0: Entity type for entity Extension 3 was not initialized!

[  310.708365] uvcvideo 1-2.3:1.0: Entity type for entity Processing 2 was not initialized!

[  310.716709] uvcvideo 1-2.3:1.0: Entity type for entity Camera 1 was not initialized!

[  310.725437] input: CX3-UVC as /devices/70090000.xusb/usb1/1-2/1-2.3/1-2.3:1.0/input/input4

[  310.726003] usbcore: registered new interface driver uvcvideo

[  310.726006] USB Video Class driver (1.1.1)

[  311.662184] usb 1-2.3: USB disconnect, device number 5

[  311.917025] usb 1-2.3: new high-speed USB device number 6 using tegra-xusb

[  311.938896] usb 1-2.3: New USB device found, idVendor=04b4, idProduct=00c3

[  311.938903] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[  311.938907] usb 1-2.3: Product: CX3-UVC

[  311.938911] usb 1-2.3: Manufacturer: Cypress

[  311.940507] uvcvideo: Found UVC 1.10 device CX3-UVC (04b4:00c3)

[  311.942140] uvcvideo 1-2.3:1.0: Entity type for entity Extension 3 was not initialized!

[  311.950615] uvcvideo 1-2.3:1.0: Entity type for entity Processing 2 was not initialized!

[  311.961983] uvcvideo 1-2.3:1.0: Entity type for entity Camera 1 was not initialized!

[  311.973516] input: CX3-UVC as /devices/70090000.xusb/usb1/1-2/1-2.3/1-2.3:1.0/input/input5

[  314.117384] usb 1-2.3: usb_suspend_both: status 0

However, it's impossible to get the stream running, neither OpenCV, Guvc, VLC, V4L have been able to give me an actual image..
So I just thought 'Ok, let's just debug through the CDC interface', but this one is not recognise either.

See report of sudo dmesg for UVC + CDC interface firmware:

[ 1181.438918] usb 1-2.3: new high-speed USB device number 11 using tegra-xusb

[ 1181.462045] usb 1-2.3: New USB device found, idVendor=04b4, idProduct=00f3

[ 1181.462115] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 1181.462165] usb 1-2.3: Product: WestBridge

[ 1181.462212] usb 1-2.3: Manufacturer: Cypress

[ 1181.462619] usb 1-2.3: SerialNumber: 0000000004BE

[ 1212.189895] usb 1-2.3: USB disconnect, device number 11

[ 1212.413706] usb 1-2.3: new high-speed USB device number 12 using tegra-xusb

[ 1212.435694] usb 1-2.3: New USB device found, idVendor=04b4, idProduct=00c3

[ 1212.435701] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[ 1212.435706] usb 1-2.3: Product: CX3-UVC

[ 1212.435710] usb 1-2.3: Manufacturer: Cypress

[ 1212.437480] uvcvideo: Found UVC 1.10 device CX3-UVC (04b4:00c3)

[ 1212.441078] uvcvideo 1-2.3:1.0: Entity type for entity Extension 3 was not initialized!

[ 1212.449238] uvcvideo 1-2.3:1.0: Entity type for entity Processing 2 was not initialized!

[ 1212.457347] uvcvideo 1-2.3:1.0: Entity type for entity Camera 1 was not initialized!

[ 1212.465475] input: CX3-UVC as /devices/70090000.xusb/usb1/1-2/1-2.3/1-2.3:1.0/input/input9

[ 1212.465944] cdc_acm: probe of 1-2.3:1.2 failed with error -22

[ 1213.469985] usb 1-2.3: USB disconnect, device number 12

[ 1213.737699] usb 1-2.3: new high-speed USB device number 13 using tegra-xusb

[ 1213.845906] usb 1-2.3: New USB device found, idVendor=04b4, idProduct=00c3

[ 1213.845944] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0

[ 1213.845967] usb 1-2.3: Product: CX3-UVC

[ 1213.845990] usb 1-2.3: Manufacturer: Cypress

[ 1213.865448] uvcvideo: Found UVC 1.10 device CX3-UVC (04b4:00c3)

[ 1224.003255] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.

[ 1229.123320] uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 34).

[ 1229.131667] uvcvideo: Failed to initialize the device (-5).

[ 1229.139637] cdc_acm: probe of 1-2.3:1.2 failed with error -22

I tried to find an explanation for the lines:

UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.

uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 34).

uvcvideo: Failed to initialize the device (-5).

cdc_acm: probe of 1-2.3:1.2 failed with error -22

Without being successful..
I was hoping that someone of you would have the answer for this.

I've attached the current state of my firmware to this post so you can have a look at it.
Let me know if I can provide anything else to help you understand the issue.

In the mean time I'll keep looking for a fix on my side.

Thanks in advance for you help!

Greg

0 Likes
1 Solution
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

The issue could be due to a bug in the CyU3PDebugPrint() which returns without releasing mutex lock in certain scenario. The attached library(debug build) fixes it and can be tested.

Please note that this fix will be included from FX3 SDK 1.3.5 onwards and the attached library is not an official release and only for debug purpose.

Regards,

Hemanth

View solution in original post

0 Likes
25 Replies
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

The attached firmware handles GET_DEF (PROBE control) request - line 996 of cycx3_OV9782.c file.

It sends 34 bytes as expected.

In spite of this, Linux UVC driver is complaining of non-compliance.

I have seen in other communities that many people have faced it with other UVC devices too. One of the suggestions was to modify QUIRKs. But I do not think this is a good way to handle this, as the device firmware supports GET_DEF request. - You can just try it for debug purpose (Link: https://sourceforge.net/p/linux-uvc/mailman/message/29832729/

https://www.ideasonboard.org/uvc/faq/ )

It would be helpful if you can take an USB trace to check the request from host and response from the device.

Regards,

Hemanth

Hemanth
0 Likes
GrAU_4638336
Level 4
Level 4
25 replies posted 10 replies posted 10 sign-ins

Hi Hemanth,

Thanks for your message, the linux host I am using is a Jetson Nano and does not contain QUIRKs as mentioned in the post linked. For that reason I can't use this temporary fix.

I will record the USB trace through Wireshark and add them to a message below.

Although I don't understand why the "GET_DEF (PROBE control)" issue is showing up when the CDC debug interface is active and not when the production mode is enabled. This don't make sense since this part of the code is not modified by CX3_DEBUG_ENABLE.

It also seems that the CDC debug interface is raising the error, as cdc_acm: probe of 1-2.3:1.2 failed with error -22 is displayed before the GET_DEF (PROBE).

Is there some specific compliance needs that are not match in my firmware for this interface?


Thanks for you help,

Greg

0 Likes

Hi Hemanth,

I have been able to run the firmware example using the CDC interface (OV5640).

However, there were an issue with linux that some people will encounter. So here is a the fix.

When dmesg is throwing cdc_acm 2-1.1:1.2: failed to set dtr/rts, this is most likely due to modemmanager trying to use the port.
You can avoid this by typing sudo apt-get purge modem manager in a terminal. Then the serial communication port is accessible without error.

Sadly, I'm still not able to use my own firmware for the same purpose, which let me think that there is mismatch between the two configurations. I'm going to cross check my work but if someone have a clue of what is causing the issue, a hint would be really much appreciated.

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

Thank you very much for posting the fix for the issue.  This will help a lot of people facing this issue.

Regarding your project, please try commenting out CyU3PThreadSleep(1000);  in CyCx3AppInit() - suggesting this suspecting a timing issue in Host-device communication during enumeration.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hermanth,

My pleasure!

I already reduced this value to (100) yesterday and the firmware was behaving the same. I've tried your suggestion on commenting out the Sleep statement, this is making the device to crash. I believe the DmaChannelCreate / ChannelReset need this thread sleep to work properly.
I have also removed the mpicsiwakeup() in all the switch/case resolution functions and put the XShutDown statement above after the MipicsiInit function. This was creating a double call of the Thread Entry.
However this does not fix my current issue...

I have other lines in the dmesg:

[ 5850.952479] usb 1-2.3: Device not responding to setup address.

[ 5851.164453] usb 1-2.3: Device not responding to setup address.

[ 5851.375703] usb 1-2.3: device not accepting address 22, error -71

Any thought on that?
I'm running out of idea..

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

Is it the same firmware posted above, which is giving the error: device not responding to set address. If not, please mention the change done to the firmware.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hermanth,

I believe the only changes I applied are the ones mentioned above.

I've attached the last version of it, just in case.

I pretty the Setup address issue above is not really important at the moment, it can happen only randomly while programming the CX3.

The UVC Probe control which is the potential real blocker happened every single time.

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

Ok. So, the error "UVC non compliance - GET_DEF(PROBE) not supported", comes only for your firmware(even after purge modem manager is called) and not for OV5640 project. Am I correct?

Regards,

Hemanth

Hemanth
0 Likes

Hi Hermanth,

Absolutely correct!
I can also provide the OV5640 custom example that I'm using.

Thanks,

Greg

0 Likes

Hermanth,

I should notify you that, compare to the OV5640 example, my image stream is never available until the serial communication terminal has been open.

This could be one reason for that issue.

EDIT: And the OV5640 is using USB3.0 whereas OV9782 is using USB2.0, don't know if that can help..

I have crosscheck the uvc.c files and they are pretty much the same. Really hard to explain what is happening!

I'm not able to figure why this is happening.

Greg

0 Likes

Hi Cypress,

This topic is still a blocker for me, do you have any hints to let me progress on this issue?

As a reminder:

  • OV5640 example firmware working without problems on Windows and Linux host
  • Custom Firmware OV9782 not working on Linux
  • Custom debug firmware OV9782 working on Windows only if the CDC interface is opened
    If the firmware in used in release mode (without CDC interface) image stream can be acquired normally on Windows (not working on Linux).
  • Both have been tested under USB2.0
  • Messages given by dmesg command on linux is as follow:

UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.

uvcvideo: Failed to query (129) UVC probe control : -110 (exp. 34).

uvcvideo: Failed to initialize the device (-5).

cdc_acm: probe of 1-2.3:1.2 failed with error -22

Attached is the current state of the firmware.

Thanks in advance for your help,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

I do not see CDC class request handling in the attached firmware. Can you please comment on the same.

Also please attach OV5640 firmware which works on Linux.

Regards,

Hemanth

Hemanth
0 Likes

Hi Herman,

I have been following the attached firmware example.

Which does not seem to have any CDC class request?

Could you provide an example of what you are expecting?

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

I was referring to the section Handling CDC Requests and Adding CDC Functionality section of the KBA: Adding Communication Device Class Interface to FX3 Firmware - KBA229099

When you mentioned "OV5640 example firmware working without problems on Windows and Linux host", were you able receive debug log information on the host? And did you test with the project attached in your last post?

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

I've deleted some of the print statements that were in the callback funcions.

Now it is fully functional when DEBUG is enabled.

Video stream of the OV5640 is running whether or not the CDC interface is opened.

Debug logs can be acquired whether or not the video stream is opened.

Let me know if it is not the case for you.

In the meantime, I will have a look at your link.

Thanks,

Greg

0 Likes

Hi Hemanth,

I have checked your article but it does not look to correspond to the use case made in my OV5640 example.

Moreover the simplified version used in firmware attached above is working as expected.

I'm still unable to give any explanation on why mine is different that the example and does not allow video stream without CDC interface active.

Did you find something on your side?

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

I do not have any finding yet.

With the removal of the debug print statements, I understand that OV5640 project is running irrespective of CDC interface being open. Is this both in linux as well as Windows?

With the removal of this debug prints, is OV9782 project running on Linux when CDC interface is open?

Can you please try commenting out every debug print statement in OV9782 project and then try in Linux? - just for debug.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

Yes, only the removal of the print statements in the callback functions. For example the "size of frame: ...." print statement is correctly displayed in OV5640 firmware above.

So, I have double check, this firmware is working on both Linux and Windows WITH USB3.0.

However the the OV5640 firmware does not work on Linux if used with a USB2.0 but works on Windows.

Is there specific requirements that are not met on the USB2.0 interface?

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

There can be bandwidth issues with USB 2.0

And it is not recommended to use debugprints in callbacks.

Secondly, can you please let me know if your firmware (OV9782) works with CDC interface open/closed by removing the debugprints in callbacks.

Regards,

Hemanth

Hemanth
0 Likes
GrAU_4638336
Level 4
Level 4
25 replies posted 10 replies posted 10 sign-ins

Hi Hemanth,

Yes of course! I've never intended to put print statements in the callback functions and the ones you saw where implemented before.

They are now all removed. 

I have tested your suggestion and I found a really interesting behaviour after commenting all the print statements.

When all the debug print statements where commented out, the firmware wasn't working anymore. The device couldn't not properly enumerate in Windows.

I went through all the statements one by one until I found out where the issue was introduced.

In the AppThreadEntry function, triggered by a CX3_USB_SUSP_EVENT_FLAG, when the CyU3PMipicsiSleep(); is called without putting a CyU3PThreadSleep(10); in front of it, the firmware is crashing. It would have been hard to find this out without your recommendation, so thank you!

Now the image stream is working as expected even when the CDC is not opened.

I have also tried to re enable the print statements and it seems to work all good now!

Next step is to test this in Linux, I will keep you posted.

Thanks,

Greg

0 Likes
GrAU_4638336
Level 4
Level 4
25 replies posted 10 replies posted 10 sign-ins

Hi Hemanth,

I have couple of updates. First of all, I've noticed that the stream is not working consistently when some print statements are added.

I don't think that the USB interface is overloaded. I'm streaming 400x400x2 at 30 fps. The USB speed should not be a problem, right?

I have also tried to use the camera on my Linux host with none of the print statements. Even with that, the CDC interface is not correctly initialised.

Same issue:

cdc_acm: probe of 1-2.1:1.2 failed with error -22

I still can't get the video stream on the linux host and I obviously have nothing to debug since the CDC interface is not accessible.

Any idea for these issues?

Thanks,

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

Please do the following:

1. Handle the CDC class request in your firmware. Please check below project for your reference.

Using CyU3PDebugPrint API to Send Debug Messages over USB-CDC Interface from FX3 Firmware – KBA23147...

This project is not for cx3. But you can only see the CDC request handling for reference.

2. Do not call Debug print API in your firmware

    a. any where in callbacks

    b. anywhere in the firmware until CyU3PDebugInit() is called

Please let me know after testing above.

If above did not work, then please take a USB trace and share it with me.

Regards,

Hemanth

Hemanth
0 Likes

Hi Hemanth,

I did as you requested, or at least I believe so. The CDC interface is still working after the changes.

Although the stream is running correctly, it cannot be open a second time when the print statement "size of the frame:..." is sent.

To be clearer:

1. CX3 Flashed

2. Image stream opened and running

3. Image stream closed

4. Image stream opened but not running anymore

5. CDC interface opened, image stream is running again.

I have attached the new version of the firmware to that message.

I have tested this version which includes the CDC request Events on Linux. I'm still facing the same issue.

I have also tried without any print statement at all, without being successful.

I have attached the USB traces for the device:

  • Devide plugged
  • Device flashed
  • Image stream called

Let me know if you can find something interresting.

Thanks,

Greg

0 Likes

Hi Hemanth,

This is still an issue for me. Have you found something useful in the documents I provided?
Thanks for your help!

Greg

0 Likes
Hemanth
Moderator
Moderator
Moderator
First like given First question asked 750 replies posted

Hi Greg,

The issue could be due to a bug in the CyU3PDebugPrint() which returns without releasing mutex lock in certain scenario. The attached library(debug build) fixes it and can be tested.

Please note that this fix will be included from FX3 SDK 1.3.5 onwards and the attached library is not an official release and only for debug purpose.

Regards,

Hemanth
0 Likes