Maximun speed of interruptions on STM32F429

[lopezcontreras]

Dear all,

I need geneate an interruption about 5Mhz to access to an external device using FMC. I am trying to use a Timer to generate that interrupt but I do not get the results I expect. On STM32F429 and STM32CubeIDE, I config timer 10 with the following setup:

• Internal APB2 42Mhz
• Preescaler 0
• counter mode up
• counter period: 41
• Internal clock division: No
• auto-reload: Disable.

I understand well, with this setup, I divide clock 42Mhz/42= 1Mhz, but not even get 1Mhz.

Does anyone knows if this I am doing is correct?

What is the maximum interrupt frequency I can get?

Is there any other way to get an even up to 5Mhz?

Thanks in advance,

Joaquin.

[Ozone · Accepted solution]

Any subsequential interrupt from the same source is only executed once the handling of the current one is finished.

Cube/HAL is known to relocate an awful lot in interrupt routines and callbacks.

Interrupts can quickly load up a fast MCU, it involves context save/restore, not only your code.

At a certain point, the core is 100% saturated with interrupt entry and exit alone.

The Cortex M core was not designed for efficient handling of very high interrupt loads.

I would suggest to utilize peripherals, or consider a DSP.

[lopezcontreras]

Thank you very much for you support.

I understand there is not a way to get an event/interrupt at those frequencies in the MHZ range.

Regards,

Joaquin.

[Nikita91]

I evaluated the interrupt capacity of an F429 clocked at 168 MHZ.

A timer generates an interrupt that does absolutely nothing. You can go up to about 1.8 MHz for 100% CPU usage by the interrupt.

To achieve this you must use a "zero latency interrupt".

http://adastra-soft.com/zero-latency-interrupt/

[Ozone]

You might get an interrupt working at that rate, I never attempted to count the cycles for you configuration.

The question is - what you could actually do in that cycle, considering the 12 cycles you already need for context saving (and another 12 for restauration).

There is hardly any time (core performance) left for your application.

[Tesla DeLorean]

The ceiling drops precipitously when you actually do anything, and is compounded by all the drag surfaces Cube/HAL want to bring with them.

Beyond a few hundred KHz one should seriously consider the merits of the approach, and either use hardware to perform the task, or decimate the interrupt loading with a more considered solution.

[Tesla DeLorean]

If you need MHz interrupts you are approaching the problem from the wrong direction.