UVC Firmware based on AN75779 not working after SDK update to 1.3.4

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

cross mob
JuBa_297206
Level 2
Level 2

Hi,

after the SDK update to 1.3.4 our firmware based on AN75779 is not working anymore. Using the JTAG connection of the SuperSpeedExplorerKit I could trace it down to the MultiChannelDMA used for video data transfer. All API functions used to send data return CY_U3P_SUCCESS, but I do only get CY_U3P_DMA_CB_PROD_EVENTs and no CY_U3P_DMA_CB_CONS_EVENTs. Therefore it seems to me, that the problem is located within the DMA implementation. The results of USBPCap show, that there is no data arriving at the PC side.

Does anybody have an idea, how to proceed to locate the problem within the dma channel functions? Which changes were made to MultiChannelDMA in preparation of SDK 1.3.4?

We added a CDC device for configuration and this is still working well, such that the implementation of the SingleChannelDMA is not affected.

Thanks and best regards,

Judith

0 Likes
1 Solution

Hello Rashi,

I proceeded in checking our custom firmware against the AN75779 firmware and finally it turns out that I need to call CyU3PDmaMultiChannelReset between the calls of

CyU3PDmaMultiChannelCreate and CyU3PDmaMultiChannelSetXfer. So I suppose that the reset function initializes/resets something more than the create function...

But finally: We got it!

Thank you very much for your help and patience!

Have a nice weekend,

Judith

View solution in original post

0 Likes
17 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello Judith,

Please refer to the FX3 release note in the SDK. It points to the changes in certain API's from v1.3.3 to v1.3.4.

Please confirm if you use any of it in your firmware.

Can you share the API's you called which are related to dma multichannel?

Regards,

Rashi

Regards,
Rashi
0 Likes

Dear Rashi,

thank you for your quick response. I checked the release notes before posting, but could not get a hint out of them. I will prepare a mimimal example that I can share with you, but this will not be before October 7th, because I will be out of office next week.

The functions we use are:

CyU3PDmaMultiChannelCreate

CyU3PDmaMultiChannelSetWrapUp

CyU3PDmaMultiChannelGetBuffer

CyU3PDmaMultiChannelCommitBuffer

CyU3PDmaMultiChannelReset

CyU3PDmaMultiChannelSetXfer

Thanks and best regards,

Judith

0 Likes

Hello Judith,

It doesn't seem that there is any problem with these API (when you change SDK version).

Till you provide the firmware, can you provide the USB traces ( can you wireshark ) to know why the CONS EVENT are not generated.

Regards,

Rashi

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Dear Rashi,

sorry for the delay. Please find attached the minimal example and a wireshark/USBPcap trace.
Today I got 8 packets but then the data path freezes again.

Kind regards,

Judith

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Judith,

I went through the traces but fount that BULKIN URB from host are not there. Please confirm.

The CONS event would be generated when you get request from the host application (BULKIN URB)

I tried building the firmware with the AN75779 application note with 1_3_4 library and it is working fine. This firmware was initially build with 1_3_3 library.

As you mentioned, that you got 8 packets (i.e 8 CONS event would have been generated).So, it seems there is no problem with API's (library).

I tried the firmware you attached in previous post but couldn't reproduce due to differences in sensor and also the GPIF interface.

1) So can you toggle the GPIO and check the PROD event and CONS event (number) and share the traces. If you are getting BULKIN URB from host and still the CONS event doesn't happen then there will be a problem on FX3 side (i.e in firmware).

2) Also can you check the default firmware AN75779 (build with 1_3_4 lib)  with your sensor and the same host application and get the usb traces

Please find the attachment for difference between the traces  (tested in USB 2.0)

Regards,

Rashi

Regards,
Rashi
0 Likes

Dear Rashi,

the attached trace from my last post (usb_trace.pcap) contains 8 URB BULKIN. Please try the following filter:  usb.addr == "3.25.3".

Unfortunately I was not able to count PROD- and CONS_EVENTS today because I had some trouble with my JTAG Connection.

As suggested I tried to use the firmware example from AN75779 with my sensor and I get a Video stream out of it, but much to slow (round about 10 times slower than usual). So at least there must be timing issue. Please have a look at the attached traces to compare the differences in time.

Thank you very much for your help and best regards,

Judith

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Judith,

I found that you are using  io_cfg.isDQ32Bit        =  CyTrue; (32-bit bus width)

Can you try changing the Clock configuration that i have attached

setting the system clock to 400MHz (Try with AN75779 as well as you custom firmware)

What is the PCLK frequency fed to FX3?

If this doesn't work, i would need the timings between the CONS and PROD Events (you can debug this by toggling a GPIO). Please Capture  share the traces (please test for both the firmware)

Regards,

Rashi

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hello Rashi,

sorry I forgot to mention, that my custom application already uses the changed clock configuration. Our sensor typically works with a PCLK of about 70 MHz but can be up to 100 MHz (or even more) depending on the application. I changed the example of AN75779 accordingly but it seems to have no effect.

Please find attached the new traces. In my custom app (compiled with sdk 1.3.4) the traces show, that I send 12 packets (device 4.10.3) but on the toggling GPIO I don't see a single CONS_EVENT. In the AN75779 example compiled with 1.3.4 I see CONS_EVENTS after 95-98µs. In my custom app compiled with SDK 1.3.3 the CONS_EVENTs are round about 90µs after the PROD_EVENTs.

Thanks for your help,

Judith

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Judith,

As you measured it not that significant delay (5us) when you checked for AN75779 on 1.3.3 and 1.3.4. This delay can be because of low level of changes in the APIs.

Can you tell how are you changing the SDK 1.3.4 from 1.3.3.

As you said, that custom firmware is working fine in SDK 1.3.3 can you share the outputs of the PROD and CONs event (by toggling GPIO). Change the SDK library by changing the variable to 1.3.3 and also 1.3.4 and share the GPIO traces.

It seems there is problem in the custom firmware or the Host application. Are you getting any debug prints when you are only committing 8 or 12 buffers (as in previous usb traces). Because if the buffers are committed to the Host there should be the CON event.

Regards,

Rashi

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hello Rashi,

please explain a little bit more in detail, what you mean with "changing the variable to 1.3.3 and also 1.3.4". Please find attached the GPIO toggles of the firmware compiled with SDK 1.3.3 and SDK 1.3.4 where rising edge means PROD event and falling edge means CONS event. As there is no CONS event with SDK 1.3.4 we can not identify the different PROD events in the image (again 12 buffers were received at PC side).

On my PC the update to 1.3.4 was done by the Cypress Update Manager. We still have a PC that has the same hardware as mine and SDK 1.3.3 installed, so I can do some tests changing the working firmware as well. We also installed SDK 1.3.4 from scratch, but until now I hadn't the time to set up the project properly on this PC.

BTW: The tests are done with a custom software as well as VLC both using the DirectShow framework, so from my point of view this should not be the problem.

I admit that it is possible that there is a bug in my firmware but up to now, I do not know where it could be. Is it theoretically possible that the CONS events are initially created but not received by the firmware because of a reset or something else happening to the DMA channel in between? Then it could be a timing problem between the different threads calling DMA channel functions.

Usually we use the UART channel for onboard communication so I first need to enable the debug prints properly, before I can share them. I will do this as soon as possible.

We also implemented a USB debug channel, but as we are using a second CDC device and the driver sometimes mixes these channels, I can not rely on that. Therefore we are disabling it by default. Is there already a new CDC Driver? We still use version 3.13.0.59.

Have a nice weekend and kind regards,

Judith

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Judith,

By variable i meant the (as shown in attachment of previous post) SDK version.

There is possibility to not get CONS event in case of DMA Reset. But 12 packets are sent, that means there should be at least 12 CONS event.

We can start debugging from scratch.

- Please install the SDK 1.3.4 from https://www.cypress.com/documentation/software-and-drivers/ez-usb-fx3-software-development-kit

- Please confirm you are changing the library path (attachment) when switching between SDK (lib) 1.3.4 and 1.3.3.

- Check AN75779 firmware works well with SDK 1.3.4 with custom software as well as VLC. Let me know the results.

- Check your custom firmware with custom software and VLC (debug prints with 1.3.4) so that we can find out where the firmware is failing.

- Please confirm that CONS event is registered in you custom firmware (attachment)

If the AN75779 firmware works fine at your end with SDK 1.3.4, then we can debug your custom firmware.

Please share the debug prints.

Regards,

Rashi

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hello Rashi,

sorry that I missed the attachment of your last post. You guys have done a great job implementing this opportunity to switch the SDK!

Actually my custom project was still compiled against "${FX3_INSTALL_PATH}\firmware\u3p_firmware\inc" and "${FX3_INSTALL_PATH}\firmware\u3p_firmware\lib\fx3_debug\", but as suggested I started from scratch on a different PC, installed the SDK and created a new project that is compiled against the directories "${FX3_INSTALL_PATH}/fw_lib/${FX3SDKVERSION}/inc" and "${FX3_INSTALL_PATH}/fw_lib/${FX3SDKVERSION}/fx3_debug" as well. So finally I can confirm that I change the SDK Version by using the build variable "FX3SDKVERSION" in AN75779 and custom firmware and thus am changing the library path accordingly. Unfortunately it makes no difference.

With AN75779 - as before - I get 4fps instead of expected 30fps both with SDK 1.3.3 and 1.3.4. Maybe because of the frame timer overflows (pls. see debug prints in attachment).

In custom firmware the CONS event is added to the list of DMA channel notifications (pls. see attachment).

The attachment contains debug prints for customFW and AN75779 both with SDK 1.3.3 and 1.3.4 initialized with "CyU3PDebugInit (CY_U3P_LPP_SOCKET_UART_CONS, 8);" as well as a code snippet showing the configuration of the DMA channel for the video stream. The debug prints of custom software and VLC are the same, so they are attached only once.

Best regards,

Judith

0 Likes

Hello Judith,

I went through the debug prints. From the debug prints the problem doesn't seem with the SDK version.

Please confirm that you are using your sensor and not MT9M114 Aptina sensor.

If you are using the some other sensor than MT9M114 Aptina sensor,  we will first debug problem with default AN75779 firmware.

As per the debug prints you are getting timer overflow due to which there will be a DMA channel reset and streaming will be stopped.

In the default AN75779 firmware, the timer is started when application starts and the timer limit is 200 ms for Super Speed.

There are two reason of this overflow:

- If the first frame doesn't come within 200 ms of starting the application.

- If the time between two frames is more than 200 ms.

So, please check whether the frame period i.e. the V_active + V_Blank (from your sensor) should be greater than timer value. so you can try increasing the timer value.

AN75779 firmware mentions about the timer value:

/* Maximum frame transfer time in milli-seconds. The value is updated for every resolution and frame rate.

* Note: The value should always be greater than the frame blanking period */

How is your custom application behaving? I didn't find anything from the debug prints.

Is it behaving the same with 1.3.3 and 1.3.4 SDK ?

Also check that you are getting proper data from the sensor side. I suspect the sensor is not providing data evenly because you are getting the data initially for AN75779 (4 fps) and then you getting timer overflow.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

I have good news! Today I had some time to debug and finally I got the AN75779 working with our sensor and the full 30Hz. The problem was in the way the GPIF is controlled in this example. I added states equivalent to FRAME_END_SCK0, FRAME_END_SCK1, WAIT_FOR_FRAME_START_1 and IDLE_SCK1 to my GPIF state machine, such that I can restart it by calling CyU3PGpifControlSWInput. Up to now the state machine was restarted only, when the overflow happened. As the time until overflow is defined 200ms - and we have to take into account some delays - this explains the 4fps. BTW: I got the 4 fps continously so the stream didn't stop completely.

Can you please explain what changes were made with respect to the creation of CY_FX_UVC_STREAM_EVENT? I saw that in AN75779 (version 10/30/2017) it is created once, whereas in a previous version (mid 2015) it was created periodically. As such the GPIF was restarted during the event handling.

To answer your questions:

- Yes we are using a custom sensor that works continously and evenly.

- Our custom software produces the same debug prints as the VLC so I only attached them once for both applications.

- Our custom firmware encounters an additional USB reset with SDK 1.3.3 as can be seen in DebugPrints_CustomFW_1_3_3.png.

Best regards,

Judith

0 Likes

Hello Judith,

Thank you for the update.

In AN75779, there s CPU interrupt in the GPIF state machine. CyU3PGpifControlSWInput is for returning back to the GPIF state machine from the firmware. CyU3PGpifControlSWInput is called in the GPIF callback.

CY_FX_UVC_STREAM_EVENT is set in the UVCHandleVideoStreamingRqts. It is set when there us UVC request from the host side i.e. when host application is opened.

So, as AN75779 is working with you sensor also with both SDK 1.3.4 and 1.3.3. It seems there is no problem with the SDK version.

Now, you can make the changes to your custom firmware keeping AN75779 as reference.

Please let me know if any queries.

Regards,

Rashi

Regards,
Rashi
0 Likes

Hello Rashi,

I proceeded in checking our custom firmware against the AN75779 firmware and finally it turns out that I need to call CyU3PDmaMultiChannelReset between the calls of

CyU3PDmaMultiChannelCreate and CyU3PDmaMultiChannelSetXfer. So I suppose that the reset function initializes/resets something more than the create function...

But finally: We got it!

Thank you very much for your help and patience!

Have a nice weekend,

Judith

0 Likes
PoHa_290941
Level 1
Level 1

I have switch from SDK 1.3.3 to SDK 1.3.4 without problems.

But I have not been able to get a 100% stabil video stream start.

Poul-Erik.

0 Likes