• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 362 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM6442: Capturing eQEP Pulse Counts in Sync on AM6442 – Possible Methods?

AM6442: ePWM ISR delayed/missed when enabling FreeRTOS on AM64x R5F

Miyako Kubota
Prodigy 30 points

Part Number: AM6442
Other Parts Discussed in Thread: SYSCONFIG

Hello,

I am using AM6442 R5F and trying to migrate a 60 Hz ePWM/eQEP‑based experimental code from bare‑metal to FreeRTOS. After enabling FreeRTOS, I am seeing delayed or sometimes missed ePWM interrupts.  

My setup is as follows:
- ePWM generates a 60 Hz STROBE signal
- The STROBE is routed internally to two eQEP modules
- Each eQEP latches its position on the rising edge of STROBE
- In the ePWM ISR, I read the latched eQEP values and call SemaphoreP_post()
- A FreeRTOS task waits using SemaphoreP_pend(), and performs the 60 Hz processing

The important point is:
- This works perfectly in bare‑metal (no RTOS).
- When FreeRTOS is enabled, the ePWM interrupt is delayed or occasionally skipped.
As a result, the eQEP latched values are not captured at the correct timing and the 60 Hz loop becomes unstable.

■ Question 1
What is the recommended way to implement a stable 60 Hz periodic task when using FreeRTOS?
Since the FreeRTOS tick (1 ms) has jitter and cannot accurately generate 16.66 ms periods, I am using the same method as bare‑metal:
      ePWM 60 Hz interrupt → semaphore → task
Is this approach (using the ePWM interrupt as the timing master) still recommended when FreeRTOS is used on R5F?

■ Question 2
Is calling SemaphoreP_post() inside the ISR valid on AM64x R5F?

■ Question 3
Under what conditions can FreeRTOS delay an ISR (e.g., critical sections, tick ISR priority)?

■ Question 4
Are there recommended settings for AM64x R5F to avoid ISR delays in this use case?


System details:
- AM6464 R5F
- 2 × eQEP
- 60 Hz ePWM STROBE (internal signal routing)
- ePWM ISR → SemaphoreP_post → FreeRTOS task
- Works 100% in bare‑metal
- Only fails when FreeRTOS is enabled

Any advice or recommended interrupt/SysConfig settings to avoid ISR delay would be greatly appreciated.

This question is related to the following previous thread:

Thank you!
  • 0
    Prodigy 30 points

    Additional information related to my previous question:

    In my bare‑metal implementation, even though no RTOS is used, I use a semaphore. the ePWM ISR posts a semaphore, and the main loop waits on it to perform the 60 Hz work. This runs with stable timing and no missed ePWM interrupts.

    When switching to FreeRTOS, I moved the waiting part from the main loop into a task.
    After enabling FreeRTOS, the ePWM ISR started experiencing delays or missed triggers.
  • 0 in reply to Miyako Kubota
    TI__Mastermind 23795 points

    Hi Miyako,

    Could you let me know what is the priority of this EPWM ISR? 

    Best Regards,

    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 30 points

    Hi Meet,

    The EPWM ISR priority is currently set to 0 (the highest priority allowed by FreeRTOS on the R5F).
    Originally it was priority 15, but I changed it to 0 as part of the debugging steps.

    However, even at priority 0, the EPWM ISR is still being delayed when FreeRTOS is enabled.

    Could you please tell me the recommended way to implement a periodic 60 Hz task on FreeRTOS without jitter or missed cycles?

    I would like to know the best practice on AM64x R5F to achieve a stable periodic task (about 16.6666666 ms for 60Hz) with minimal latency and no drift.

    Best regards,
    Miyako

  • 0 in reply to Miyako Kubota
    TI__Mastermind 23795 points
    Miyako Kubota said:
    I would like to know the best practice on AM64x R5F to achieve a stable periodic task (about 16.6666666 ms for 60Hz) with minimal latency and no drift.

    vTaskDelayUntil() can be used for this: https://www.freertos.org/Documentation/02-Kernel/04-API-references/02-Task-control/02-vTaskDelayUntil 

    Miyako Kubota said:
    However, even at priority 0, the EPWM ISR is still being delayed when FreeRTOS is enabled.

    Setting it to the priority 0 is correct but is your ISR using any of the FreeRTOS API? The thing is configMAX_SYSCALL_INTERRUPT_PRIORITY is set to 4 for R5F's freertos kernel, so if any ISR having priority higher than this uses the FreeRTOS API then it might cause some undefined behaviour, you can set the priority as 4 if this ISR is using FreeRTOS APIs. Please refer to this: https://www.freertos.org/Documentation/02-Kernel/03-Supported-devices/02-Customization#configkernel_interrupt_priority-configmax_syscall_interrupt_priority-and-configmax_api_call_interrupt_priority 

  • 0 in reply to Meet Thakar
    Prodigy 30 points

    Hi Meet,

    Thank you for your explanation.

    Regarding the 60 Hz periodic task:
    I understand that vTaskDelayUntil() is the recommended FreeRTOS method, but due to the 1 ms tick resolution and interrupt latency on the AM64x R5F, it seems difficult to achieve a perfectly stable 16.666 ms period.

    I also tested the EPWM ISR at priority 0 and at several other priorities, but the ISR still shows delay and jitter whenever FreeRTOS is running.

    From other E2E threads, it appears that EPWM interrupts can still experience latency on the R5F due to interrupt pipeline behavior and system activity.

    So my questions are:

    1. Is it realistically possible to achieve a jitter‑free 60 Hz loop on the R5F using FreeRTOS task scheduling?
    2. Or is the recommended approach to use EPWM ISR and notify a task for accurate timing instead of relying on task delays? (using semaphore)
    3. Is EPWM ISR latency generally expected when FreeRTOS is enabled on the R5F?

    Any guidance on the best practice for low‑jitter periodic control loops on AM64x R5F would be greatly appreciated.

    Best regards,
    Miyako

  • 0 in reply to Miyako Kubota
    TI__Mastermind 23795 points

    Hi Miyako,

    Miyako Kubota said:
    1. Is it realistically possible to achieve a jitter‑free 60 Hz loop on the R5F using FreeRTOS task scheduling?

    Using only task scheduling and vTaskDelay function it is not possible. this is due to the fact that FreeRTOS tick has a resolution of 1ms tick, so achieving 16.66ms precise period wouldn't be possible with this.

    Miyako Kubota said:
    2. Or is the recommended approach to use EPWM ISR and notify a task for accurate timing instead of relying on task delays? (using semaphore)

    Yes, this would be the recommended approach to get the accurate 60Hz task.

    Miyako Kubota said:

    Is EPWM ISR latency generally expected when FreeRTOS is enabled on the R5F?

    Yes, some latency is expected due to interrupt pipelines, context saving and other possible scenarios like FreeRTOS critical section, but this should be minimal, could you let me know how much delay/jitter you are currently observing. 

    If you are observing large delays then that could be coming from the critical sections of your FreeRTOS kernel code that masks interrupts above priority  configMAX_SYSCALL_INTERRUPT_PRIORITY(4). And you can't call any FreeRTOS APIs from ISRs having priority below 4, so you can't call SemaphoreP_post if your ISR has 0-3 priority, if you are doing so then it can lead to Kernel data corruption or task scheduler corruption leading to an undefined behavior.

    So yes, you could observe some delays if you are using ISR with priority above 4 and if that latency is not acceptable for you, then you can continue with the baremetal application. It would be good to know how much latency you are observing currently (should be a few us).

    Best Regards,

    Meet.