TDA4VH-Q1: SDK11.0 MSC "UDMA Output Ring dequeue failed for ch0!!"

Hello,

Assigned to expert 

Regards

Tarun 

Hi,

The simple fix is to increase the timeout value in the macro VHWA_M2M_MSC_MAX_WAIT_LOOP_CNT. The current value is 5000, can you try increasing to 10000? 

Regards,

Brijesh

I tried changing it to 10000 or 40000, but the problem did not improve and still exists.

Hi Xi,

This is strange, if the request is completed, then there should be an element in the DMA engine, are you running any other modules in the system? Are there only 5 instances of LDC and 5 instances of MSC? Is there a display or any other component running in parallel ?

Regards,

Brijesh

hi Brijesh

MCU4_0 only runs five LDC instances and five MSC instances, and no other components. MCU2_0 runs the csirx component and sends data to MCU4_0 via IPC.

Hi Xi,

Is it possible to reproduce this issue on EVM for easier debug? 

I can share a workaround to try it out, i would also like to see why this error comes. 

Regards,

Brijesh

hi Brijesh

I haven't tried this on EVM because it can't connect to our camera. You can reproduce this issue by using the A72 core to read image data from the file system and send it to MCU4_0. Can you share your workaround?

Hi Xi,

The idea is to flush the elements from the ring, just before submitting the new request and in case we get the error like, "UDMA Output Ring dequeue failed" , just ignore and see if it runs fine.. 

Regards,

Brijesh

hi Brijesh

Do you have a patch based on SDK 11.0?

Hi xi,

Can you apply attached patch on PDK folder, rebuild SDK and then try it out? 

/cfs-file/__key/communityserver-discussions-components-files/791/VHWA_5F00_Flush_5F00_Rings_5F00_LDC_5F00_MSC.patch

Regards,

Brijesh

hi Brijesh

Sorry for the late feedback — I couldn’t log in earlier because E2E was having some network issues.

I tested the patch you provided, but the issue still persists — it still shows “UDMA Output Ring dequeue mismatch for ch0!!”.

If all five MSC examples use VHWA_M2M_VPAC_1_MSC_DRV_INST_ID_0, the problem goes away, but the MSC processing time becomes too long, which doesn’t meet our requirements.

We’d still like to use two different vpacDrvInstId, so please help us look into this issue.

Hi Xi,

Are all of the above nodes use scalar0 only ? If yes, can you try different scalar output for each node instance? 

Regards,

Brijesh

All instances use VHWA_M2M_VPAC_1_MSC_DRV_INST_ID_0 for vpacDrvInstId. The last four MSC instances output four images with different resolutions, as shown in the following figure:

Hi xi,

Processing time should not change when you use different scalar, because the input path is still the same.. Can you divide like below.

MSC0 with Scalar0

MSC0 with Scalar1

MSC0 with Scalar2

MSC1 with Scalar3

MSC1 with Scalar4.

Regards,

Brijesh

hi Brijesh

Thank you for your help. Using different scalars for each instance solved the issue. The longer MSC processing time was caused by a mutex in our application, which prevented parallel processing.