AM5728: Ramdomly receiving repeated data word on McASP frame.

Hello Dimple,

What SDK are you using?

-Josue

I am using processor_sdk_rtos_am57xx_08_01_00_09, and CCS 11.1.

Thanks,

Dimple

Dimple,

Is it reproducible with a TI EVM or are you using custom board/s? 

Furthermore, is this your own application or one of the McAsp tests included in the SDK?

-Josue

It is a custom board, I have not verified if it can be reproduced on a TI EVM.
It is also a custom application.

Regards,

Dimple

Dimple,

Where in the transfer does the corruption happen? 

Other processor -> McASP Frame -> Recd. on McASP Port  of AM5728 -> Transferred to a buffer via EDMA -> copied to local buffer for processing

Based on 

Dimple Sharma said:

On the McASP bus, the data transmitted and received seems to be correct. It is only after receiving the McASP frame, one/two words don't seem to be copied correctly. 

I am assuming this is where it is ok. Is it corrupted here or here?

That is what I am trying to find out. I am not sure where the error is here or here. For copying to local buffer, I am only using the memcpy function. I replaced the memcpy with individual assigments for the 8 words, but I still see the error.  

One observation though - The EDMA destination buffer is in L2 SRAM and the local buffer was in OCMC. When I moved the EDMA buffer to L2SRAM so that memcpy would be in the same memory, it resulted in more errors than previously. This is a strange behavior.

Dimple,

Do you have access to a debugger?

-Josue

I have access to JTAG debugger - However, there is a Linux application running on the ARM core, and it is not very convenient to debug on the DSP side (also because it is optimized to to 03). We are using the method of logging to for the purpose of debugging.

Dimple,

Is the McAsp communication happening at the DSP level? No need to connect to the ARM core to view RTOS objects, system memory and load symbols and such. See the following application note https://www.ti.com/lit/an/sprac17b/sprac17b.pdf which is also applicable to AM57.

Not sure I can help much myself. I will have to confer internally for more ideas.

-Josue

Dimple,

Just improvising here, by any chance are both the starting buffer and the receiving buffer 16-bit aligned? does this make a difference?

-Josue

Yes, the buffers send and receive 16-bit aligned data. 

A question related to this issue -

The application is running based on a 20us timer and a task runs by pending on a semaphore posted by this 20us timer. 
We have observed that intermittently, the semaphore post is delayed and occurs at 27-30us, instead of 20us. We suspect this could be the reason the received data might be affected. 

The timer interrupt is given the highest priority - which is ID 4.  Events 0-3 are reserved for the Event Combiner. But we are not using the event combiner. 

The question here is - even though the timer has the highest priority, what could be affecting the timer's semaphore post from getting delayed?

Is there a way to disable Event combiner from the application as we are not using it? I tried to remove it from the .cfg file, but the application does not build.

Thanks,

Dimple

Dimple,

Will have to look into the functionality of the event combiner.

I am not sure if it is something you can disable since it is part of the C66 Interrupt architecture, I suggest you look into the following chapters for more information:

https://www.ti.com/lit/ug/sprugw0c/sprugw0c.pdf#page=169

Dimple Sharma said:

We have observed that intermittently, the semaphore post is delayed and occurs at 27-30us, instead of 20us. We suspect this could be the reason the received data might be affected. 

If you were to connect the debugger and use the ROV module you could confirm this and investigate what is causing delays.

-Josue

I will try to connect with debugger and check the RoV module.