Fastest IRQ response on STM32F04?

[Martijn Jasperse]

Posted on March 10, 2018 at 06:36

Hi all,

I'm trying to respond to an IRQ in the fastest way possible on an STM32F04. Configuring a GPIO as EXTI works, but there's a ~200ns delay even at highest priority, presumably due to the overhead of the IRQ and calling the handler. The documentation suggests up to 12 clock cycles are required, which should be ~70ns at 168MHz?

I don't mind polling for the IRQ in my main loop - the micro isn't doing anything else, and this does work with very small delay (~20ns or so) provided the pin is configured as GPIO_INPUT and not as EXTI. However, the pulse width of the IRQ is only ~20ns so it sometimes misses it if I'm just reading the pin in a loop (~1 in 10). Given the short pulse I expect this to happen, but I want to know what alternatives I might have besides using some circuitry to extend the pulse duration.

I had the idea to use a timer as a counter for the IRQ pulses, which I can then check in my main loop. If I received 1 count, then I perform the required behaviour, and if I see 2+ counts then obviously I have missed an IRQ but can be aware of this. However, I am at a total loss how to configure the timer in this way. Do I configure the timer for 'Input capture' mode using my IRQ as the pin? Or do I configure it for 'external clock' taking the clock source as my IRQ line?

Or can I somehow speed up my IRQ response? I need it to be <100ns. I'm running at 168MHz with the peripheral clocks set at max speeds. Using HAL/CubeMX.

Cheers,

Martijn

[Tesla DeLorean]

Posted on March 10, 2018 at 20:40

F04 ??

Should be able to configure the TIM to be a slave with the external clock being provided on CH1, and also input capture on the channel, which can then interrupt.

The pulse width might be an issue due to the synchronizer into the clock domain. Should confirm internal clocks by exporting on MCO  (PA8)

[henry.dick]

Posted on March 10, 2018 at 22:35

there was someone looking for something like this. while you guys have different names, the essence is the same. 

fate probably would suggest that the two of you can work together,

[Pavel A.]

Posted on March 11, 2018 at 03:13

Can it be effect of the flash wait state? 

-- pa

[Martijn Jasperse]

Posted on March 11, 2018 at 06:52

Ah, terrible typo! I meant F40x, currently the F407.

Looks like configuring TIM slave mode to 'External Clock Mode 1' and trigger source to TI1FP1 does what I was thinking of! Reference for anyone else is part 18.3.3 of RM0090. Seems mutually exclusive from input capture though? Do you know if there is a faster way to reset the counter other than explicitly assigning CNT to 0?

I looked at the MCO output, which was indeed as expected (including the PLL output at div4)

Edit: Changed reference to the correct RM.

[Martijn Jasperse]

Posted on March 11, 2018 at 06:54

I think it's a fairly common question but searching other posts I didn't gain much information applicable to my case. Do you have a reference?

[Martijn Jasperse]

Posted on March 11, 2018 at 06:55

Can you elaborate or point me towards a reference? I don't know that I've encountered this before.

[Pavel A.]

Posted on March 11, 2018 at 16:29

>

Can you elaborate or point me towards a reference?

When interrupt occurs, the handler usually is not in the instruction cache.

Some STM32 models have so called 'ART accelerator' which reduces or even eliminates wait states on the internal flash. This IMHO means that a. Flash wait stateshavesensible effect, b. Even if'ART accelerator' ispresent, it may not work 100% of the time.

Turvey.Clive.002

‌ or

Waclawek.Jan

seem to know much more about this, hope they can comment.

-- pa

[henry.dick]

Posted on March 11, 2018 at 17:55

It is not clear to me if you are trying to reduce latency or to measure short pulses . 

If you are trying to reduce latency, polling would be preferred unless you want to code a naked isr. Or, one without context saving .

You can use others like exti or timer (preloaded with -1 for an up counter).

If you are trying to measure short pulses, a hardware solution is preferred. Either a pulse extender or an asynchronous counter.

[waclawek.jan]

Posted on March 11, 2018 at 21:41

There are many factors going into interrupt latency - code memory (usually FLASH) latency, which may or may not be mitigated by cache (in 'F7 on AXIM bus) or ART in 'F4 or in 'F7 on TCM; latency of data memory where stack sits; currently executed code; any conflicts with other masters on buses in request; compiler-imposed prologue/epilogue, unnecessary code imposed by 'libraries' etc. Don't count on less than two or three dozens of cycles - and the faster the mcu, the more the latency (and its jitter) in cycles is prone to be.

In other words, whatever needs to be timed with better precision is to be done in hardware. 32-bitters have them a lot, although it may not cover all possible usage scenarios.

Ah, terrible typo! I meant F40x, currently the F407.

[...]

RM0385

RM0385 is for '

F74x. For 'F407 you want to refer to RM0090. Timers may be similar, though.

Looks like configuring TIM slave mode to 'External Clock Mode 1' and trigger source to TI1FP1 does what I was thinking of! Reference for anyone else is part 23.3.3 of RM0385. Seems mutually exclusive from input capture though?

You can still use External Clock Mode  2 (on timers which have TIMx_ETR pin) together with input capture.

Do you know if there is a faster way to reset the counter other than explicitly assigning CNT to 0?

What do you mean by 'faster'? How does 'resetting counter' match with what you've written previously?

As dhenry wrote, you may perhaps want to tell us what do you want to accomplish, first. I'd also recommend you a thorough reading of the relevant RM and other related materials (Cortex-M4 Programming Manual, ARM's Cortex-M4 TRM).

JW