We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
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?
No one as an idea what could be occurring?
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.