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)?
Please show us the real settings. It is likely that your code is buggy.
Here are the configuration for the 4 DDR partitions. RBAR is the address, first RASR line is the default setting for which I do not have any prb, the second RASR line is the new configuration with cache enable and normal memory, for which I get the HW freeze.
RBAR -> 60000000 80000000 A0000000 C0000000RASR => 03080039 03080039 13010039 13100039RASR => 03020039 03020039 03020039 03020039
Note that for the SRAM I keep the same setting:
RBAR -> 20000000 RASR => 030B0039
I understand from your reply that there should not be any limitation, so it is likely that the chip is bugged.
No, it is likely your code is buggy.
You mean the setting I am using are incorrect? Can you please be more specific? Do you confirm there is a limitation in the attribute which can be used?
Where does your code run?
NXP S32 G274A, first Cortex M7 core
In which memory region?
When you seek for help, it would be nice not to provide pure values, but decoded. Or do you expect other to decode which bits in RASR mean what?
I gave you these info in the question. I also gave the exact settings because you ask for them, suggesting the values I used were wrong. And despites the question is about the documentation, you keep accusing again and again my code of being buggy though you did not see one line of it. And now you are saying you refuse to open the reference manual. It is very nice from you to try to help, but here you are wasting your time and mine.
Your main complain is that the chip is buggy. But most likely your code is. So in order to get help, you should provide information in a way that those who may going to help you do not have to spend too much time. Sure we can decode the settings. But why should we not you?
No: if enabling the cache for partitions 0x6- to 0xE- is forbidden, then my code is bugged and not the chip. Unfortunately the doc is unclear on this point. This is the question I am asking: what does mean the doc here?
What are you seriously thinking? That I put a 1 in a forbidden bitfield, then I am going to write "I put this forbidden value in this register but then everything goes south, please help me" so you, Einstein, can answer "the forbidden value is actually forbidden, ta-dam!". The meaning of the new RASR is "cached normal memory". It is written clearly in my message since the beginning... but if you cannot understand this message, you are right: do not even try to open the ref manual.
Despite your politeness: Is the CM7 running alone or are the CA53 already running and there is some security/safety setup which causes an exception as soon as there is a cache line fill from "protected" memory?
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.