Run code from ram improve the performances?

[Paolo Andreuzza]

Hallo.

In other mcu (not ARM) i’ve worked in the past, there were possibe to move some parts of time critical code to ram, and run them from there to get the best performance, since the flash mamory access were slower then the ram access.

In STM32 mcu this tecnique gives real advantages in performance?

I've seen that some STM32 mcu (but not all) have specific hardware to improve flash access speed (ART Accelerator...), om these platform, running code from ram improves even more the performances or is not a good idea?

In particular, In STM32G070, that seems to don't have any specific hardware for flash management, running code from ram does improve significantly the performances, or is it not worth?

Thank you in advance.

Paolo

[waclawek.jan]

Let's put it in this way: in the CM0/CM0+, the processor has one single port for all accesses to all memories, so contrary to CM3/4/7, there's no room for any parallelism (hence no penalties for cases where that parallelism is not fully utilized). Accesses to RAM are (presumably) always single-cycle, so there's no way execution from RAM would be slower than execution from FLASH. OTOH, the 'L0 and 'G0 both have implemented measures on the FLASH interface to mitigate somewhat the impact of waitstates (prefetch/buffers/caches).

So, code from FLASH will most probably run somewhat slower than from RAM, and the difference may be dramatic and may be also small, depending on the particular code (assuming the buffers/caches/prefetch are not switched off, of course). Whether this benefit outweighs the drawback (RAM consumption, additional code to copy/run from RAM) is upon the user to judge.

JW

[Terry Greeniaus]

I'm just looking at RM0454 (STM32G0x0) and it seems to have most of the flash acceleration... Section "3.3.5 FLASH memory acceleration" talks about instruction prefetch and also about cache memory. It's not quite as powerful as say the STM32G4 ART, but for certain types of code it should help a lot vs. those wait states. Like others have said, benchmark it. It looks like FLASH_ACR.ICEN=1 is set by default at boot, but that you will need to set FLASH_ACR.PRFTEN=1 manually.

[Paolo Andreuzza]

thank you all