Delayed interrupts during FMC access on stm32h7 ?

[UBart.2]

tested on nucleo stm32h723 board with STM32CubeIDE (only main.c is modified)

What does this example?

Timer3 triggers an interrupt every 40 microseconds. The interrupt toggles PC8 for ~2ms. Additionally we trigger a FMC data transfer every second for 10 seconds.

What is the Problem?

Every second during the FMC data transfer our interrupt handler is somehow delayed!

The global variable "ticks_end_max" contains the maximum number of the timer3 counter register just before the interrupt ends. This max counter value is ~2600, but only ~600 if FMC access commented out!

Using an oscilloscope on pins PC8 and PC9 is also possible. PC9 is configured as TIM3_CH4 and emits a 4us low pulse each cycle. PC8 is toggled for ~2us during interrupt. Trigger on rising edge of PC8 when PC9 is low.

[UBart.2]

Please find the full STM32CubeIDE example project attached (only main.c is modifed).

[UBart.2]

It would be very nice, if someone could at least reproduce our Problem.

Until now we are very satisfied with both the STM32H7 performance and documentation. But interrupt delays of >5us (when FMC is accessed) might is a real problem for our development.

Thanks in advance!

[waclawek.jan]

Do the external memory accesses actually happen? If yes, it would be interesting to see them on the oscilloscope together with some of the above signals.

JW

[UBart.2]

The example I made is stripped down as much as possible. So the MCU-FMC pins are not configured here.

Our production code of course does real FMC accesses to an external IC (16 async microcontroller interface).

I'll try to make another oscilloscope screenshot with a probe attached to the FMC as soon as possible.

[waclawek.jan]

> #define BASE_ADDR (0x68000000U)

Are you sure?

Also note, that FMC_BCRx and FMC_BRTx are nonzero after reset, and also that FMC_BCRx bit 7 is  Reserved, must be kept at reset value and its reset value is 1.

JW

[UBart.2]

Please find attached a oscilloscope screenshot which also shows FMC_NE3. So The FMC is really executing the access. This was expected as we can talk to the externally connected IC without problems.

Interesting though, the FMC is still doing some data transfers after the timer interrupt was triggered. It seems like there is some kind of FIFO which has to be emptied before the timer interrupt is executed from internal memory.

[waclawek.jan]

The Cortex-M7 processor contains a 4-entry store buffer towards the AXI memory interface, which for Strongly-ordered memory area (and that's what you appear to have set in MPU for given FMC block) should behave as FIFO. From that scope waveform it's not quite clear if there are 4 writes to FMC between timer overflow and PC8 toggling or more. The ISR may be executing earlier, but the buffered writes may prevent the GPIO writes to be executed.

The Cortex-M7, with all the hundreds of megahertzs and caches and whatnot, optimized mostly for number crunching, is not that great for real-time operation.

JW

[UBart.2]

Thanks so much for your help! Your explanations sounds very reasonable!

Sorry for the blurry screenshots. I've had a close look at the number of transfers done. It looks more like 5 or 6 transfers after the IRQ should be triggered, but beside that your explanation sounds very reasonable.

Additionally it looks indeed like you said: the interrupt might really be triggered immediately but has to wait for to access the GPIO.

So to explain our situation a bit more: Beside an SDRAM we have attached two different ICs via FMC to the STM32H7. The first one is really slow (575us access time). The second one - which we need to access from the interrupt - is quite fast. And yes, we used 'strongly-ordered" mode for both of them.

It would be great, if you could help me now again to find a suitable way around our problem.

1) Is there any way to disable the 4-entry store buffer towards the AXI memory interface for a specific FMU region? Or to disabled it at all?

2) Is there a way to flush the 4-entry store buffer or to check the fill status? I would not mind to just call a buffer flush after each single write to the slow IC.

I'd like to thank you so so much! You really made my day!

[waclawek.jan]

> It looks more like 5 or 6 transfers

There is probably some buffering at the AXI matrix output port towards FMC ("3 write acceptance" sounds much like a buffer for 3 writes). This is an independent mechanism from the processor's store buffer, and maybe you can influence it through the AXIM registers.

> 1) Is there any way to disable the 4-entry store buffer towards the AXI memory interface for a specific FMU region? Or to disabled it at all?

I don't think so.

> 2) Is there a way to flush the 4-entry store buffer or to check the fill status? I would not mind to just call a buffer flush after each single write to the slow IC.

Quoting from Cortex-M7 TRM:

The store buffer is drained of all stores to Strongly-ordered or Device memory before a load is

performed from Strongly-ordered or Device memory.

JW

[UBart.2]

First of all much thanks to @Community member​ who was completely right!

Then I might to point out that the title of the thread is misleading. Not the interrupt itself is delayed. Only the first memory access which uses AXI is delayed.

We now simply execute a dummy read (which also uses the AXI) after every write to the very slow IC that is connected via FMC. This way we prevent the AXI buffer to get filled up with our very slow memory writes.

Although this is not an elegant solution, the measures overhead in our case is less than 1%.

Would be interesting to hear if someone has a better solution?