TDA4VM: [J721E][TDA4VM][AUDIO][MCASP][UDMA]The issue of audio channel data offset

Hi bean lai,

Can you share your code that you are using to set up the MCASP?

Best,
Jared

Hi bean lai,

TRM about buffer overrun:

A buffer overrun occurs when a serializer is instructed to transfer data from XRSRn shift register to XRBUFn
receiver buffer, but the corresponding MCASP_RBUFn register has not yet been read since the last time the
transfer occured. When this occurs, the receiver state machine sets the overrun flag - ROVRN. However, the
individual serializer writes over the data in the XRBUFn buffer register (destroying the previous sample) and
continues shifting (n = 0 to 15).

An overrun is checked only once per time slot. The MCASP_RSTAT[0] ROVRN flag is set when an overrun
condition occurs. It is possible that an overrun occurs on one time slot but then the host catches up and does not
cause an overrun on the following time slots. However, once the ROVRN flag is set, it remains set until the host
explicitly writes a 1 to the ROVRN bit to clear the ROVRN bit.

Do your settings line up with the speed of the data coming from the upper computer?

Best,
Jared

Yes, the clock signal of the upper computer is provided by the TDA4VM side.

Hi bean lai,

Is there something else running on the C6 that could stall the MCASP from clearing the FIFO in time?

Best,
Jared

We use C6x_2 to handle the audio process alone, while the other processes run on other cores and use UDMA for handling.Indeed, this issue occurs when all peripherals are connected, such as CMOS and screens. However, it is fine if there is only audio

BR

My main question is whether there are any areas in mcasp & udma that can be optimized without modifying other processes.

BR

Is this related to the FIFO threshold setting in mcasp or the UDMA ring buffer setting? No matter how I adjust them, the ROWRN problem still occurs.

BR

Hi bean lai,

bean lai said:

Indeed, this issue occurs when all peripherals are connected, such as CMOS and screens. However, it is fine if there is only audio

My guess is there is some stall from DDR usage due to the screens. Can you test whether there is a specific peripheral that is causing the issue?

bean lai said:

Is this related to the FIFO threshold setting in mcasp or the UDMA ring buffer setting? No matter how I adjust them, the ROWRN problem still occurs.

Increasing the FIFO size wouldn't hurt, but I assume it's an issue with transactions being stalled due to higher priority requests taking precedence.

You can try QoS settings:  [FAQ] TDA4VH-Q1: How do I control the quality of service (QoS) and class of service (CoS) settings on TDA4 devices to balance transaction loads and priorities?  

Best,
Jared

I also suspect that it's an issue with transactions being stalled due to higher priority requests taking precedence.

The udma priority of the audio has been adjusted to the highest.

Hi bean lai,

Jared McArthur said:

You can try QoS settings:  [FAQ] TDA4VH-Q1: How do I control the quality of service (QoS) and class of service (CoS) settings on TDA4 devices to balance transaction loads and priorities?  

Can you try following the instructions in the FAQ to see if the transactions are truly running at the highest priority?

Jared McArthur said:

Can you test whether there is a specific peripheral that is causing the issue?

Can you also do the above?

Best,
Jared

Jared McArthur said:

Can you test whether there is a specific peripheral that is causing the issue?

Can you also do the above?

[beanlai]: This has been tested; plugging in a CMS camera increases the probability of recurrence.

You can try QoS settings:  [FAQ] TDA4VH-Q1: How do I control the quality of service (QoS) and class of service (CoS) settings on TDA4 devices to balance transaction loads and priorities?  

Can you try following the instructions in the FAQ to see if the transactions are truly running at the highest priority?

[benalai]: The FAQ is a bit long; I need to understand it. Or could you provide more intuitive suggestions for me to try?