How to fix slow interrupt latency

Question

How to fix slow interrupt latency

Michael Fowler 131

Hello,
I have written an ISR that calls tx_semaphore_put() to wake a thread that is waiting for the semaphore using tx_semaphore_get(). There is only the one thread on the system. It takes 5 micro seconds for the thread to begin running. This is too long. How do I ensure my high priority interrupts are handled in a timely manner? Thanks.

AshokPeddakotla-MSFT 35,971 Reputation points Moderator

2022-07-25T15:50:31.773+00:00

@Michael Fowler
Wanted to follow up with you to understand whether the below information helped. Please let us know if there are any other queries.
If below suggestions answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.
AshokPeddakotla-MSFT 35,971 Reputation points Moderator

2022-08-01T09:29:06.453+00:00

@Michael Fowler Just checking in to see if the answer helped. If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

1 answer

Your answer

AshokPeddakotla-MSFT 35,971 Reputation points Moderator

2022-07-25T15:50:31.773+00:00

@Michael Fowler
Wanted to follow up with you to understand whether the below information helped. Please let us know if there are any other queries.
If below suggestions answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.
AshokPeddakotla-MSFT 35,971 Reputation points Moderator

2022-08-01T09:29:06.453+00:00

@Michael Fowler Just checking in to see if the answer helped. If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

Answer 1

Scott Azure RTOS 4,051

This should take no more than 2 microseconds on a Cortex-M device running at 120MHz. What processor are you using and what is the processor clock speed?

Are you doing anything in the ISR after putting the semaphore?

Michael Fowler 131 Reputation points

2022-07-16T19:35:04.4+00:00

Thanks Scott,
I'm using the iMXRT1050 at 528MHz. The isr just clears the interrupt and puts the semaphore. I see the same delay on both a pin and spi interrupt.
Michael
Scott Azure RTOS 4,051 Reputation points

2022-07-16T20:13:20.817+00:00
How are you measuring the latency? Using the Cortex-M cycle count register?

Do you have a semaphore notification callback function registered? This function would be called from tx_semaphore_put in your ISR.

I'm going to assume that while your thread is suspended waiting for the semaphore, the ThreadX scheduler is spinning in the idle (__tx_ts_wait) loop.

Can you measure the following times:

how long tx_semaphore_put takes to execute.

how long it takes from the return of tx_semaphore_put to getting back into the __tx_ts_wait loop in the scheduler.

Basically, I want to find out where the majority of that 5us is spent.

Thanks!
Michael Fowler 131 Reputation points

2022-07-16T20:16:55.053+00:00

Thanks Scott,
I used and oscilloscope to measure. I'm new to RTOSs, what's the best way to take the measurements you requested?
Michael
Scott Azure RTOS 4,051 Reputation points

2022-07-18T17:04:21.947+00:00

Are your pin and SPI interrupts both calling tx_semaphore_put?

Are you toggling a pin and measuring that with the scope? If so, toggle at (1) the start of the ISR, (2) before the call to tx_semaphore_put, (3) after tx_semaphore_put returns, and (4) in the __tx_ts_wait loop.
Michael Fowler 131 Reputation points

2022-07-18T19:03:17.28+00:00

Hi Scott,
Both interrupts call tx_semaphore_put but on a different semaphore. Should I be using tx_semaphore_put_notify instead? I'll work on measuring the timing,
-Michael
Scott Azure RTOS 4,051 Reputation points

2022-07-18T19:15:59.163+00:00

No, you don't need to use tx_semaphore_put_notify.
Michael Fowler 131 Reputation points

2022-08-02T20:52:40.68+00:00

I have measured the interrupt latency at over 3 uSec.
Here is the ISR:

void GPIO1_GPIO_COMB_0_15_IRQHANDLER(void) {
uint32_t pins_flags = GPIO_GetPinsInterruptFlags(BOARD_INITPINS_ADC_RDYB_GPIO);
static uint32_t count = 0;
if (BOARD_INITPINS_ADC_RDYB_GPIO_PIN_MASK
== (pins_flags & BOARD_INITPINS_ADC_RDYB_GPIO_PIN_MASK)) {
count++;
st=SysTick->VAL;
assert(TX_SUCCESS == tx_semaphore_ceiling_put(&adcReady, 1));
}
GPIO_ClearPinsInterruptFlags(GPIO1, pins_flags);
SDK_ISR_EXIT_BARRIER;
}

Here's the thread:

static VOID adc_reader_thread_entry(ULONG arg) {
TX_THREAD_NOT_USED(arg);
uint32_t adc = 0;
uint32_t adcChannel = 0;
uint32_t data[4] = { 0x10, 0x11, 0x12, 0x13 };
uint32_t status = tx_thread_resume(&uploader_thread);
assert(TX_SUCCESS == status);
while (1) {
status = tx_semaphore_get(&adcReady, TX_WAIT_FOREVER);
uint32_t newST =st - SysTick->VAL;
if (status != TX_SUCCESS) {
PRINTF("ERROR waiting for ADC\r\n");
continue;
}
}
}

As you can see I'm measuring the SysTicks between the two function calls. There are 1851 clock cycles between the put and the get. Thats over 3uSec on the 600MHz M7.
Scott Azure RTOS 4,051 Reputation points

2022-08-03T17:43:40.017+00:00
Hi @Michael Fowler

Thanks for posting your code and measurement.

Can you measure the following times:

how long tx_semaphore_ceiling_put takes to execute. Just read SysTick again after the assert() in your ISR. Let's call this st_post_put.

how long it takes from st_post_put to get back to the label __tx_ts_restore in the scheduler. https://github.com/azure-rtos/threadx/blob/b871c33620f9b58a83e92a33f4ca00025e850c7f/ports/cortex_m7/gnu/src/tx_thread_schedule.S#L217

to read the SysTick in assembly, insert the following two lines into tx_thread_schedule:

__tx_ts_restore: // INSERT THE FOLLOWING TWO LINES MOV r4,#0xE000E018 // Load address of SYST_CVR LDR r4,[r4] // Read SYST_CVR into r4 // END OF INSERTED LINES LDR r7, [r1, #4] // Pickup the current thread run count

This loads the SysTick Current Value Register into r4. Put a breakpoint on the LDR r7 instruction so that you can manually measure the difference (st_post_put - r4).

Thanks!

Share via

How to fix slow interrupt latency

1 answer

Your answer