RTOS/AM5728: GPIO interrupt latency on IPU

Reona Shiode

Prodigy 215 points

Part Number: AM5728

Tool/software: TI-RTOS

Hello,

I was using GPIO5-7 pin to trigger the ISR on IPU1.

IPC was running on IPU1 and Linux loaded image file of IPU1 firmware. Those were based MessageQ examples.

GPIO5 was used by linux in default, so GPIO5 node in device tree was removed completely.

IPU1 had Timer11(clocked by external 10 MHz and used for periodic task), Timer14 (used for Clock module) and GPIO7-7pin (used for measuring interrupt latency).

I used PDK GPIO driver for driving GPIOs and handling ISR.

I measured GPIO interrupt latency.

It seemed that the results were affected by the period of Timer11.

When the period of timer11 was 100usec, the latency was 40 usec at least.

period 1000 usec, latency 600 usec.

1000000 usec, the latency was very large.

I think GPIO interrupt latency is affected by the period of timer module.

If not, I want to know the way to reduce this latency.

Best Regards,

Reona

over 6 years ago

0 Garrett Ding over 6 years ago

TI__Mastermind 43296 points

Reona,

The GPIO latency issue was discussed in a few threads -
e2e.ti.com/.../756351
e2e.ti.com/.../666621

If you look for a lower latency GPIO operation, we recommend to use the PRU to toggle GPIO.

Regards,
Garrett

0 Reona Shiode over 6 years ago in reply to Garrett Ding

Prodigy 215 points

Thank you for reply! Garrett

I have seen the second threads, but not first. I checked that.

I want to achieve that M4 core application processes the GPIO interrupt event with low latency.

It is not necessary to toggle the GPIO pin fast.

Could m4 core react to PRU interrupt event faster than GPIO interrupt event?

And I'm still wondering that the latency of GPIO interrupt seems to be affected by the period of timer module.

Best Regards,

Reona

0 Garrett Ding over 6 years ago in reply to Reona Shiode

TI__Mastermind 43296 points

Reona,

The IRQ (Hwi) interrupt latency should be correlated to cycle numbers rather than system ticks, for example, file:///C:/ti/bios_6_75_02_00/packages/ti/sysbios/benchmarks/doc-files/GCC_A15F_ti_platforms_evmDRA7XX_time.html (though this is not for IPU core).

I don't think the M4 core reacting to PRU interrupt will be faster than GPIO event. From TRM 30.1.6.2.2 PRU-ICSS Interrupt Controller System Events Flow, the extra mapping of system event to host interrupt should cause more delay.

Do you measure the latency using oscilloscope?

Regards,
Garrett

0 Reona Shiode over 6 years ago in reply to Garrett Ding

Prodigy 215 points

Garrett,

My apologies for the late reply.

If the latency is correlated to cycle numbers, I think that the period of timers is not related to the latency , but the cpu frequency is.

Howevere, the cpu frequency is set default value, the latency is changed by timer11's period.

When clock source of timer11 is 20 MHz system clock, the latency is range about 4 to 9 usec.

When clock source is 10 MHz external clock and gpio input is 100 Hz generated by that ext clock, the latency is about 7 to 8 usec.

I seem that the IRQ(Hwi) do not interrupting, but polling with timer 11's period.

>Do you measure the latency using oscilloscope?

Yes, I do.

The latency I mentioned is defined that the time between rising edge of gpio input and gpio output.

Best Regards,

Reona

0 Garrett Ding over 6 years ago in reply to Reona Shiode

TI__Mastermind 43296 points

Reona,

I can't think of any reason the timer 11 for a periodic task would affect a GPIO IRQ latency, and want to confirm the Timer14 (used for Clock module) is "responsible for the periodic system tick that the kernel uses to keep track of time...The Clock module is used to schedule functions that run at intervals specified in clock ticks." I will loop in RTOS kernel expert to comment upon your confirmation...

Regards, Garrett

0 Reona Shiode over 6 years ago in reply to Garrett Ding

Prodigy 215 points

Garrett,

It was improved by using CTM[0] instead of timer14.

But, I cannot understand the reason why.

Is it better to use CTM[0] for Clock module than gptimers?

And new problem occur. the latency is bad and have jitter during linux booting but after boot, the latency is small and have no jitter.

I thought the cause is that it is heavy loaded in L4_PER1 interconnect because linux accesses many peripherals in booting. But timer9' ISR is low latency and no jitter in spite of connecting through L4_PER1. So the load of L4_PER1 is not related i think...

I want know the way to improve this latency.

Best Regards,

Reona

0 Garrett Ding over 6 years ago in reply to Reona Shiode

TI__Mastermind 43296 points

Hi Reona,

I am currently out of the office, will investigate this after I return to the office in the July.

Regards,

Garrett

0 Garrett Ding over 6 years ago in reply to Garrett Ding

TI__Mastermind 43296 points

Reona,

Any progress on the GPIO interrupt latency issue from your side? I am back in the office, will be looking into this as well ...

Regards,

Garrett

0 Reona Shiode over 6 years ago in reply to Garrett Ding

Prodigy 215 points

Garrett,

I found out the reason why the GPIO interrupt latency was large in linux booting process.

Because, idle mode of GPIO that is removed in dtb becomes smart-idle and GPIO driver do not set wake-up enable.

I don't know why the GPIO latency was settled down atfer linux booting process was complete. But, I can avoid from that situation by setting no-idle-mode or wake-up-enable.

For removing GPIO from dtb, I redefined the GPIOn node in dts like following.

But, this is not used for setting idle-mode.

&gpion {
        status = "disabled";
        ti,no-idle;
        ti,no-idle-on-init;
        ti,no-reset-on-init;
};

Best Regards,

Reona

Processors

Processors forum

RTOS/AM5728: GPIO interrupt latency on IPU