Hi, We are facing issue with the execution of PWM ISR timing. The PWM timing on HW pin is fine. Isuue observed the entry time of ISR have a timing distrubance periodic. The project is built with freeRTOS. without RTOS there is no jitter.
To reduce the complexity, created a simple freeRTOS project with etPWM1 configured with center aligned up-down counter of 40 uSec period. RTOS configured with ony one task, which will update 50% dutycycle of PWM. The PWM ISR is configured with ZERO count event. Measurement of ISR period is done with 1. toggle gio and use the oscilloscope 2. Use RTI 1 counter to capture the period.
Attahed the scope result and analysis of memory capture of the RTI counter.
We have tried to modify the interrupt priorities of RTI 0 and etPWM 1, still have the jitter. We have observed the jitter is periodic with 60 mSec.
Tried by removing the etPWM1 and use only RTI 1 interrupt and measure the RTI 1 ISR period. This measurement also show the jitter with 60mSec period.
I have attached captures of the scope and spreadsheet capture.
I am unable to upload my project as a new user prompt.
Is it possible for you to share additional implementation details like, FreeRTOSConfig.h, how PWM ISR is handled, are there any FreeRTOS APIs being called in the ISR and priority of the other tasks running?
Hi Tony,
The post not allowing me to share the project files or the share link, and it says resticted for new users. Any other way to share my project with you.
sekhar.india
@sekhar.india The FreeRTOS kernel does mask interrupts sometimes, by necessity, for critical sections. It seems that you are periodically seeing ISRs delayed by ~12 microseconds when using FreeRTOS. That could be a fairly typical delay for periodic FreeRTOS operations in a critical section. Is the delay a problem for you? Or are you just looking for an explanation?
If it’s a problem, you can likely reduce the delay by increasing the CPU clock rate.
Also note that the Cortex R5 port allows you to configure FreeRTOS’s interrupt masking to leave the highest interrupt priorities unmasked, even in critical sections. Those ISRs will not be delayed by the kernel’s occasional interrupt masking. (Not noticeably delayed anyway.) However, those ISR’s are not allowed to make calls to the FreeRTOS API functions. See configMAX_API_CALL_INTERRUPT_PRIORITY.
Hi Jeff,
Thanks. That means, this is a known periodic delay in the RTOS execution.
I am executing time critical function in the ISR. I do not expect any delay during entry of the ISR.
I have tried to search the configuration in the project to see for configMAX_API_CALL_INTERRUPT_PRIORITY. Did not found any instance. Can you please provide more insight how this can be configured to unmask RTOS interrupts? I am not using any RTOS APIs in my ISR.
Which port are you using? For example, portable/GCC/ARM_CR5/.
In that port you should get a build error if configMAX_API_CALL_INTERRUPT_PRIORITY is not defined. See this line. It would typically be defined in FreeRTOSConfig.h.
See here for more information about interrupt config. The page says Cortex A but it applies to Cortex R5 too. RTOS for ARM Cortex-A
I am using portable/GCC/ARM_Cortex-R4, as I am using TI controller and CCS development.
Looks like in the port, it is not implemented. I have searched both kernel include and source folders.
Do u see any other options?
Your options depend on the interrupt controller TI provided in your device. Unfortunately I’m not familiar with your device. If it has the GIC then the R5 port code would work directly. If it’s a different interrupt controller, then you could potentially modify the port to mask interrupts only up to a certain level.
Yes it appears so. I looked at the Reference Manual, and the interrupt controller seems to be proprietary. It doesn’t provide any way for the port to mask interrupts up to a certain level, which explains why the port is written as it is.
Could you clarify how you adjusted the interrupt priorities?
One suggestion would be to move the etPWM1 interrupt from channel 90 (default) to channel 2, and then either move the RTI1compare0 interrupt (default 2) to a higher numbered channel, or use a different RTI interrupt for the OS tick.
This would mitigate one source jitter where the higher priority tick interrupt is occurring while the PWM interrupt is being handled. The drawback is that you are effectively deferring the OS tick while processing the PWM. If the ISR handler is short, this may be an acceptable tradeoff in your application.
As pointed out above this would not the source of timing jitter where a critical section is preventing all interrupts from being processed.
Another approach would be to investigate using the NHET2 instead of the PWM. This is effectively a high precision timer unit that executes asynchronously from the CPU core. The NHET2 could generate your waveform and implement other minimal logical operations without the need to interrupt the CPU core.
The API will allow to modify the priority of the ISR.
" vimChannelMap(2, 3, &vPortPreemptiveTick);"
I have tried to make PWM as highest priority ISR. Still I see the jitter. Looks like some other RTOS kernel task, which might be masked, is interrupting with 60mSec period.
