>>> I don't believe they are off.
> SCB-> CCR = 0x40200, read before memset call clearly show that both the caches are off. If you mean something else pls specify more detailed.
No, I meant this.
Okay, so this may be the more complex case (as compared to instruction cache being switched on). As there's no caching, the processor requests each instruction word from FLASH. Instructions are 16-bit wide and go through a 6-stage pipeline to the asymmetric two-core execution unit (as KnarfB noted above), processor fetch is probably 32-bit wide (I am lazy to look it up), it goes through the 64-bit axi bus to the FLASH controller. FLASH is 256-bits wide (qword) and is accessed through a 3-qword read queue, see FLASH read operations/Read operation overview in RM. Add branch prediction to the mix. Detailed behaviour of all the components mentioned above is simply undocumented.
I would expect that the behaviour would vary at any position within the 256-bit window; and also depend on previous execution state, short sequence making this more pronounced - exactly as you've experienced:
>Here are the measurements for different sizes:
>bytes slow fast
>B us us
>64 5.11 0.99
>640 45.4 5.22
>6400 120.88 48.42
>64000 220.72 152.74
where you can see, that not only the relative difference decreases but also execution time per transferred word decreases too, with increasing number of loops.
>>>Which RAM?
>dummy as locally defined array, defined in AXI-SRAM. But its address is the same in both cases, so i do not see why this matters
Writing to RAM goes throught the AXI matrix too. That's by no means a passive interconnection; it's a beast, again poorly documented. It may well be that writes are delayed for some reason (e.g. to group them together into dwords) and that then slows down subsequent writes and that this is somehow dependent on the relative phase between various involved clocks; but this of course is just a pure speculation and doesn't sound to be the main reason for the difference here.
The "optically" high processor speed brings higher number crunching capabilities, but the real-time-control aspect generally stays the same as it used to be.
In Cortex-M7, generally, the TCM buses (and associated memories) are intended to bring down the uncertainties/jitter; but they of course have their own set of issues, and the uncertainties inherent in the processor (stemming from dual-issue, branch prediction etc.) remain.
Welcome to the wonderful world of 32-bit mcus.
JW
