Hello,
I am working on a SoC with several Cortex M7 cores. It has SRAM mapped to region 0x2000_0000 and DDR mapped to 0x6000_0000 -> 0xDFFF_FFFF.
It seems that configuring the 4 regions of DDR to cached normal memory is triggering an HW bug which freezes the whole chip. Even the debugger get disconnected. Note that I do not need to access the DDR to raise the problem. Just configuring the MPU then running code in SRAM will, after a random delay, trigger the bug.
Is there any limitation to the attributes I set when configuring the MPU?
I would say only the system space in 0xE000_0000 has fixed attributes, but I have a doubt because if I refer to ARMv7-M arch ref manual, I can for instance find this:
"B3.1 The system address map"
"A declared cache type can be demoted but not promoted"
I am not sure here if this is just a limitation during runtime or an absolute limitation that forbids enabling the cache for partitions at 0xA... and 0xC... as they are not enabled in the default address map.
Also, the documentation indicates that the DDR is normal memory, but is there any problem if I keep it configured by default as device memory (without taking into account non reordered accesses inherent to this configuration)?
Or this is the problem:36.1.6 Speculative access of DDR memoryBefore you initialize DDR, speculative access of DDR memory can generate fault or unexpected behavior. Therefore, you mustconfigure the core programming to disable speculative access of this region.
The SoC contains several CM7 and CA53, and additional cores like CM0 for specialized HW modules. However, only one CM7 is booted, which will initialize the core itself (including the MPU), the SRAM, the clocks, a few GPIO, the UART and a few other basic HW modules. It will then do benchmarking tasks like copying big arrays in memory. The DDR is not initialized nor accessed.
If the MPU is using default attributes for the DDR partitions, it will run fine. If we only change the DDR attributes to cached normal memory, the system will freeze after usually a few seconds, though it may vary depending on parameters like array size or for loop count.
Note here that I am not interested on hints about why there would be a crash due to SW. It is just not possible to help without having the setup in your hand and spending days on it. What I just want to know is if there is official limitations coming from ARM about the settings used for the MPU and more specifically what does means exactly "A declared cache type can be demoted but not promoted".
And sorry for being impolite, but keep in mind it is still more polite to accuse somebody of being Einstein than writing bugged code when you know nothing about the piece of SW or the chip in question ; moreover when the question is just about getting a clear explanation of one sentence in the ref manual.
Antoine C said:The DDR is not initialized nor accessed.
I suspect this the root cause of your problem. Or a speculative read from the un-initialized DDR-RAM.
You may try to _not_ map the DDR and see if you get an exception.
Antoine C said:What I just want to know is if there is official limitations coming from ARM about the settings used for the MPU and more specifically what does means exactly "A declared cache type can be demoted but not promoted".
My experience with this is, that you can set for example 0x8000_0000 as WB, but it will still be treated as WT (hence cannot be promotet).
So the range A000_0000 -> DFFF_FFFF is _always_ XN!
I do not understand why "The DDR is not initialized nor accessed" would be the "root cause" of anything. Why would it be a problem to only use the SRAM ?
Also, there is *no* read to or from the DDR. And it does not seem there is an exception triggered, as it would be just caught by the debugger. Here the debugger is totally disconnected.
Regarding the cache setting and XN, I can modify my program and put then run some code or data in the DDR at 0x6- or 0xA- and run it successfully (at least once by playing with some parameters), and the XN or the cache settings will be correctly taken into account, so that is different from what you are saying. Also, why XN could not be unset for 0xA- => 0xE- ? I did not find such limitation in the doc.