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

AN555, SSE-310, Cortex-m85, MPS3 FPGA image: No MPC controller is mentioned for Internal SRAM

The image document states an SRAM controller (in 0x57000000) for the range 0x01000000 - 0x011FFFFF (NS) and 0x110000000x111FFFFF (S). I configured the SRAM region to secure and non-secure for code that works correctly (Fig 5). The stack for the secure world uses internal SRAM, and I am trying to configure 0x21040000 - 0x21040818 to NS (fig 2). The SAU is configured correctly, but the document does not mention the MPC controller address for internal SRAM (fig 3). When I switch to NS the execution perfectly goes to the Non-secure reset handler (setup stack, setup MSPLIM, PSPLIM, etc.) (fig 4). In program_start(), there is a push instruction to PUSH PC, but this instruction does not push any value to the stack. And when the POP PC instruction executes, it pops "0" from the stack generating a hard fault (fig 1).

Fig 1: Push instruction does not push any value to the stack (NS)

I am guessing as the SAU is configured without configuring the MPC, the memory region is not properly configured for NS.

Please let me know if any other causes may lead to this error or if the error is because MPC is not configured, please let me know the controller address for that region (could not find it in the document).

Fig2: Internal SRAM region:

Fig 3: Available MPC controllers:

Fig 4: Branch to Program_start() from Non-secure reset handler:

Fig 5: SAU configuration

Thank you very much for your time.

Parents
  • Hi,

    only thing I can say is it looks like NS does not have all the proper permissions to use that memory.

    I had a similar situation (not identical) with STM32U585 where, when RTOS was starting it wanted to load stack frame from SRAM memory which in the GTZC (global TrustZone® controlle) did not have properly set permissions for NS to access that memory.
    The result was that instead of stack frame information the content that was read from memory was all 0, no other exception was triggered thus it ended up loading PC with 0 like in your case and like in your case ended up in Hard Fault.

Reply
  • Hi,

    only thing I can say is it looks like NS does not have all the proper permissions to use that memory.

    I had a similar situation (not identical) with STM32U585 where, when RTOS was starting it wanted to load stack frame from SRAM memory which in the GTZC (global TrustZone® controlle) did not have properly set permissions for NS to access that memory.
    The result was that instead of stack frame information the content that was read from memory was all 0, no other exception was triggered thus it ended up loading PC with 0 like in your case and like in your case ended up in Hard Fault.

Children
No data