How to avoid interrupt latency or timing jitter (and get hardest real time possible)

[_ThomasLorenz_]

Hi

We have a system set up with iMx CPUs running freeRTOS (there we have a 1ms and 5ms cyclic task).

We also run lwip stack. The fast realtime routine are running interrupt triggered (ADC conversion end irqs, prio 1 and 2 and PWM reload prio 3).

Just to be precise the ADC conversion is triggered by PWM reload/compare event.

Set interrupt priorities are these:

#define NVIC_PRI_RESET (-3) // Not configurable
#define NVIC_PRI_NMI (-2) // IRQ -14, Not configurable
#define NVIC_PRI_HARDFAULT (-1) // IRQ -13, Not configurable
#define NVIC_PRI_ADC1 (1U) // IRQ 119 ADC1 complete (main pwm start), highest fast prio
#define NVIC_PRI_ADC0 (2U) // IRQ 118 ADC0 complete
#define NVIC_PRI_WAV (3U) // IRQ 102, Pattern generator, lowest fast priority
#define NVIC_PRI_DISABLE_ALL_BUT_FAST (7U) // Warning: Same as configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h
// Value for basepri to disable all interrupts except the motor control ones.
// Don't call rtos functions from higher priorities, (-3 to 3).
#define NVIC_PRI_SDCARD (8U) // IRQ 110, USHDC1 for SD Card
#define NVIC_PRI_LPUART (8U) // IRQ 20, LPUART for serail port
#define NVIC_PRI_LPSPI (8U) // IRQ 33, LPSPI2 for serial flash
#define NVIC_PRI_SD_CD (9U) // IRQ 85, GPIO3 inputs 16 - 31, SD card detect
#define NVIC_PRI_ETHERNET (9U) // IRQ 114, Ethernet
#define NVIC_PRI_PENDSV (15U) // IRQ -2, Request for priviliged access
#define NVIC_PRI_SYSTICK NVIC_PRI_PENDSV // IRQ -1, RTOS tick

In the code I meassure start (signal ... S) and end (signal ... E) of the irqs by latching the PWM timer PWM1->SM[0].CNT

When having a look on those timer values I see significant jitter (glitches) on the timing - see picture attached (3500 is about 50us). HOW could it be improved (harder real time, less jitter).

Note: IRQ table is copied in fast (internal) RAM, all routine code running in the fast irqs is placed in internal RAM.

Regards

Thomas

[ErichStyger]

Yes, BASEPRI is set by

configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY

But I see you have it set to

NVIC_PRI_PENDSV 

which is rather unusual, and in conflict what is written as comment in your first post, that it should be 7?

#define NVIC_PRI_DISABLE_ALL_BUT_FAST (7U) // Warning: Same as configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h

I don't say that this is the problem, but I think you have some mismatch here at least?

And of course: whatever you do in a ISR will have an impact to all the other ISRs with numerically lower interrupt urgencies, so this could be your problem.

[_ThomasLorenz_]

Hi

In config.h I see

#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY NVIC_PRI_DISABLE_ALL_BUT_WAV

so it should be OK.

All the ADC interrupts how lower prio number so they shall be higher prior than the RTOS.

I wonder if cache misses or such could cause significant jitter (10 to 20us).

 And If so how to avoid/improve?

Regards

[_ThomasLorenz_]

1) it is i.mx RT 1061 and 1021

2) it is a mixture of both. As we have 3 fast irq routines (one tied to adc conversion chain 1 (start and end shown by 2: and 3: in the picture) end and the other two tied to adc conversion chain 2 end (conversion is done two time each cycle)  (with a multiplexer in that irq, start of first routine is 4:, start and end of 2nd event/routine is ch 5 and 6) if e.g. interrupt 1 take much to long it will shift start of subsequent irq to a point after the "nominal" starting point. 

Thomas

[ErichStyger]

Hi @_ThomasLorenz_ ,

I'm not clear about the chart/data you showed.

At what interrupt priority is the interrupt in question (PWM?) running? I don't recognize it in your interrupt list.

As a general note: keep in mind that everything numerically equal or higher than the BASEPRI will be masked by the RTOS, so you will see some jitter there.

In case you have not seen it: I have a series about ARM Cortex Interrupts with FreeRTOS or any other RTOS usage here:

https://mcuoneclipse.com/2016/08/14/arm-cortex-m-interrupts-and-freertos-part-1/

https://mcuoneclipse.com/2016/08/20/arm-cortex-m-interrupts-and-freertos-part-2/

https://mcuoneclipse.com/2016/08/28/arm-cortex-m-interrupts-and-freertos-part-3/

I hope this helps,

Erich

[_ThomasLorenz_]

Hi

It is these two priorities:

#define NVIC_PRI_ADC1 (1U) // IRQ 119 ADC1 complete (main pwm start), highest fast prio

This irq sriggers code where timing is meassurend in ch 2 and 3 (main start and end)

#define NVIC_PRI_ADC0 (2U) // IRQ 118 ADC0 complete

This irq runs twice (at two point of time) and triggers code where timing is meassurend in ch 4 (starting point speed routine, 1st time irq call)  and 5/6 (current start and end, second time irq call)

If I understand our code correctly by setting the freeRTOS base irq configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY higher it should not interfere with our fast code:

#define NVIC_PRI_DISABLE_ALL_BUT_FAST (7U)

// Warning: Same as configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY in FreeRTOSConfig.h
// Value for basepri to disable all interrupts except the motor control ones.
// Don't call rtos functions from higher priorities, (-3 to 3).

Thomas

[jingpan]

Hi @_ThomasLorenz_ ,

I have some questions.

1. What chip do you use, i.mx or i.mxRT?

2. I'm not understand the picture clearly. What does jitter(glitch) mean? Do you mean the interrupt service time too long, from beginning to the end? Or the service time isn't stable, some times long and some times short.

Regards,

Jing

[_ThomasLorenz_]

1) it is i.mx RT 1061 and 1021

2) it is a mixture of both. As we have 3 fast irq routines (one tied to adc conversion chain 1 (start and end shown by 2: and 3: in the picture) end and the other two tied to adc conversion chain 2 end (conversion is done two time each cycle)  (with a multiplexer in that irq, start of first routine is 4:, start and end of 2nd event/routine is ch 5 and 6) if e.g. interrupt 1 take much to long it will shift start of subsequent irq to a point after the "nominal" starting point. 

Thomas