STM32F0 Interrupt Latency and operating time of the interrupt

[vlad23]

Posted on June 21, 2016 at 14:56

Hello!

There MK STM32F0. It works at a frequency of 48 MHz. Background program is an empty infinite loop. In front of the signal on the output MCU configured external interrupt. The interrupt handler only operation with I/O ports and logical operations.All used pins are configured to operating at maximum speed. According to the article

https://community.arm.com/docs/DOC-2607

 Interrupt Latency for core Cortex-M0 is 16 machine cycles. The first command after entering the handler, I read one of the I/O port, and then other pin is set to high level. The time between the leading edge of the external signal that caused the external interrupt, and a high level of this pin is 800 ns. Why is so much time and how to reduce it?The same article refers to the jitter time of reaction, but it is unclear what factors he can depend on?The interrupt handler time was 1.5 microseconds, which is also surprisingly high. Also I will be glad to advice how to reduce it.Used Keil 5.17. I tried different levels to optimize the compiled code optimization on time / code size. Do not give positive results. Placing an interrupt handler in RAM is possible to reduce the operating time of 0.2 microseconds, but did not affect the Interrupt Latency.

[waclawek.jan]

Posted on June 21, 2016 at 16:20

From the article you quoted:

The interrupt latency listed in table 1 makes a number of simple assumptions:

• The memory system has zero wait state (and with resources not being used by other bus masters)

You presumably run code from FLASH. There are wait states for reading code from FLASH at the maximum execution speed. Also, you probably use a high-level language, presumably C. It compiles a single statement into multiple machine instructions. JW

[Tesla DeLorean]

Posted on June 21, 2016 at 16:59

The interrupt automatically stacks context, depending on the entry/exit dynamics, tail-chaining can eliminate the context restore/save between two serviced interrupt.

This can result in a jitter, and could be observed if you advance/retard the separation of the two interrupt triggering events by one clock cycle.

[vlad23]

Posted on June 22, 2016 at 08:47

Now interrupt is run from Flash, but I tried to run it from RAM.

This reduced the run time of 0.2 microseconds.MCU operating at frequency is 48 MHz. For this frequency flash has 1 WS. Prefetch buffer is enabled.Interrupt handler is coded in C.All other interrupts are disabled.

[AvaTar]

Posted on June 22, 2016 at 08:53

> The first command after entering the handler, I read one of the I/O port, and then other pin is set to high level.

And to how much machine instructions does this actually evaluate ?

[vlad23]

Posted on June 22, 2016 at 09:17

62: uint_fast16_t db = GPIOC->IDR & 0x1FFF;

63: uint_fast8_t data; 64: 0x08000242 4833 LDR r0,[pc,#204] ; @0x08000310 0x08000244 8A00 LDRH r0,[r0,#0x10] 65: GPIOB->BSRR = GPIO_BSRR_BS_12; 66: 0x08000246 2101 MOVS r1,#0x01 0x08000248 04C0 LSLS r0,r0,#19 0x0800024A 0CC0 LSRS r0,r0,#19 0x0800024C 4A31 LDR r2,[pc,#196] ; @0x08000314 0x0800024E 0309 LSLS r1,r1,#12 0x08000250 6191 STR r1,[r2,#0x18]

[waclawek.jan]

Posted on June 28, 2016 at 21:27

Okay, so that is 8 instructions. Of those, three read data, that is one or two cycles (I am not that good in cycle counting in the ARMs) per read (two here read from FLASH, that's another 2*1 waitstates penalty). There are some cycles until the write propagates to the pin. This all together is at least 12 cycles, but as I don't know very well how to count the read/write timings, I'd assume it's more like 15 or 16 cycles, from the ISR beginning to the pin change.

Also, there were some cycles at the input side spent: there is a synchronizer in the input, there is at least one cycle spent in the edge detector of the EXTI, then there will be at least one cycle between EXTI and NVIC. All this, together with the 16 cycles for the ISR invocation may quite easily end up in the 35 or so cycles pin-to-pin latency you are experiencing. You could cut down a couple of instructions by performing the port write as the very first operation in the ISR, i.e. before the port read and masking; but I suspect it was the port read you really wanted to have a low latency rather than the pin toggle, which I believe is just a tool to visualize the latency. I'd expect the port read to happen some 10 cycles earlier than the output pin changes. Don't expect anything better. Face the reality: these are NOT microcontrollers, but SoC. For hard and fast real-time timing use hardware - if there is no built-in fitting the bill, add external. JW PS. Tell us your application. We might come up with a better solution (or not).