AM5728: [AM5728] Task hangs when triggering EDMA under TI RTOS

Hello Daewon,

Could you share more information about what RTOS SDK you are using and any logs ore ROV error logs?

I will be reassigning your thread to our RTOS engineer.

-Josue

Thank you for your response.
I'd like to share an update based on the results of additional testing.

We are using processor_sdk_rtos_am57xx_09_03_00_00, and initially encountered an issue on AM5728 under TI-RTOS where all Tasks entered the Idle state and stopped responding when EDMA was triggered.
The PCIe communication is managed through a state machine consisting of two main Tasks:

- One Task operates every 100 µs to check whether the EDMA transfer should be triggered and whether it has completed. When a transfer completes, an ISR (Interrupt Service Routine) is invoked, which sets a completion flag. This flag is then periodically checked by the Task.

- The other Task runs every 500 ms to prepare new data and initiate the next EDMA transfer request.

Separately, to ensure proper system initialization, we added an Event-based synchronization mechanism so that each Task waits until all others are fully ready before proceeding. This was not added as a workaround for debugging, but rather to ensure that the system enters a well-defined initial state before executing the main logic.

After introducing this synchronization mechanism, the issue no longer occurred — EDMA functioned correctly and all Tasks behaved as expected.

However, since this mechanism was not specifically designed to fix the issue, we are still unsure about the root cause of the original problem.
Could you advise what might have caused all Tasks to enter the Idle state in the previous case, or suggest any diagnostic approaches we could take to identify similar issues?

I'd like to make a correction to my previous comment.
It turns out that the issue still persists — the system continues to exhibit the same behavior where all Tasks stop responding.

Specifically, we observed that the system remains stuck inside the Load_idleFxn(Void) function. This suggests that all other Tasks may have been preempted or blocked, and the system has transitioned into the Idle state without returning to normal operation.

We're currently investigating what might be causing this behavior, but any insight into why the system might end up stuck in the idle loop would be greatly appreciated.