I am using Arm Musca-A1 in a project and I'm getting a strange behavior on the MPC connected to the internal SRAM0. During boot, I am loading some data to SRAM0 (S region). While when I access the memory perspective and watch the S and NS addresses of SRAM0, I only can see the data through the NS address (0x20000000), which afaik isn't the expected behavior.
As I read in the "Arm ® CoreLink TM SSE-200 Subsystem for Embedded (Revision: r1p0)", SRAM memories are secure at boot ("The cfg_init_value of each MPC is tied to 0 so that at boot, the SRAM is Secure only. Software must change or restore the settings in the MPC to release memory for Non-secure world use.").
In further tests, I notice that SRAM0 is the only showing this behavior, since the remaining banks are mirroring the data only in their respective secure address. In this tests, I am loading two words at the start of each memory bank. Just take a look on the following shots:
SRAM0 (S addr)
SRAM0 (NS addr)
SRAM1 (S addr)
SRAM2 (S addr)
SRAM3 (S addr)
Am I missing something while addressing this issue? Because it seems that MPC that controls SRAM0 is configuring the memory as non-secure in boot. Can anyone elaborate on this?
After further investigation, I discover that Musca-A1 and B1 the first 8KB of SRAM0 is not accessible to the debugger, which explains this strange behavior. If I perform the same tests in the 0x30002000/0x20002000 address, everything seems correct.
I notice this errata on target-specific scripts of pyocd debugging tool. Afaik this is not stated in Musca docs, which would be a good revision.