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)?
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.