This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Arm Musca A1 - SRAM0 MPC Security attribute during boot

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.