Just for info:
armclang optimizes memcpy() in a weird way (seen for ARMv7e-M), not respecting the order of access.
So a memcpy(RBAR, mputable,...) failes :(
I would not be surprised if I had seen this before, but the ARM clang memcpy does the weirdest accesses I have seen so far. In the last 30+ years, I have never seen a memcpy which did not do it with increasing addresses. But "always been so" is of course no rule ;-)
Hi again Bastian,
I discussed this issue with some colleagues.
Rather than memcpy(), you may want to make use of CMSIS functions such as ARM_MPU_Load()https://arm-software.github.io/CMSIS_5/Core/html/group__mpu__functions.html#gafa27b26d5847fa8e465584e376b6078a
They also suggested the 'Optimizing the MPU programming' section of the below blog:https://blog.feabhas.com/2013/02/setting-up-the-cortex-m34-armv7-m-memory-protection-unit-mpu/
Ronan
Roman, the problem is not the MPU programming. But the strange order of memory accesses of the memcpy. Any device which wants a linear order of accesses would fail. I am using memcpy on a lot of different platforms with a multitude of compilers, and never saw a behavior like this. But maybe the C standard allows it, I do not know.
Ronan Synnott said:They also suggested the 'Optimizing the MPU programming' section of the below blog:
He uses memcpy(). The reason for aliasing rabr and rasr was to allow memcpy to quickly program up to four regions.