This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6678 Memory Protection Unit deny access

Hi,

I'm trying to use the Memory Proteciton Unit of the C6678 to deny accesses to the CFG space of the slave devices.

As to my understanding of the SPRUGW5 document I have to clear all the AID fields to deny the accesses. (page 15). But when set all AID field to 0 nothing happens every access is granted.

So next I cleared the complete MPPA register (AID and SR, SX, SW, ...) to '0'. But the result was the same: every access is granted.

Only when I set the AID-bit to '1' (for the corresponding master) and set access mode register bits (SR, SW, ...) to '0',  the access is succesfully denied.

Can someone please explain me the meaning of the AID-Bit fields?

Thanks.

  • The bolded wording below from pg 15 defines the functionality exactly as you described it to be working.  If AID is 0, then it won't bother to check MPPA settings, if AID is 1, it will check them.

    The MPU first checks the transfer’s privilege ID against the AID settings. If the AID bit
    is 0, then the range will not be checked. If the AID bit is 1, then the transfer secure and
    debug parameters are checked against the MPPA values to detect an allowed access.
    • If NS =1, then the range is non-secure and any security or debug level may access
    the range.
    • If the NS = 0, then the range is secure only and only secure level accesses are
    allowed.
    • In secure mode if EMU = 1, then debug accesses are allowed.
    • If EMU = 0, then debug accesses are not allowed.

    Best Regards,

    Chad

  • Thanks for the quick reply.

    But when I look at the Table 3-11 on page 25 of SPRUGW5 ist says:

    Controls access from ID = 15
    0 = Access denied.
    1 = Access granted.

    This completely disagrees with the observed behavior. I thought the MPU checks the AID-bit, if it's set to '0' it does not check the MPPA parameters values, because the access is always denied. Only if the access is granted by the AID-bit the MPPA parameters are checked to finally decide if the access is granted.

    Regards Fabian

  • My Problem is, that I want to block the access to certain CFG spaces for all but one master. I thought I could achieve this by setting only the corresponding AID bit for the allowed master to '1' and allowing the read & write accesses through the MPPA parameters.

    This method does grant access for the chosen master indeed, but it does not deny the any access of any other master.

    This behavior of the MPU is quiet weird in the way that it allows accesses to a master when the corresponding AID bit is cleared. This conflicts clearly with the corresponding datasheet (Table 3-11)

    Any Idea how to solve this problem?

    Regards Fabian

  • Hi,
    I am trying to implement the memory protection feature in C6678. While I can find both Sys/Bios and CSL APIs for protection of L1P/L1D/L2Cache, I cannot find the Sys/Bios APIs for protection of shared MSM and DDR memory. Are there some Sys/Bios APIs for protection of MSM/DDR( or more precisely for managing XMC registers)? or CSL APIs are the only way to configure the memory protection registers in the XMC?

    Regards
    Nikhil
  • Hi Chad,
    I am trying to implement the memory protection feature in C6678. While I can find both Sys/Bios and CSL APIs for protection of L1P/L1D/L2Cache, I cannot find the Sys/Bios APIs for protection of shared MSM and DDR memory. Are there some Sys/Bios APIs for protection of MSM/DDR( or more precisely for managing XMC registers)? or CSL APIs are the only way to configure the memory protection registers in the XMC?

    Regards
    Nikhil
  • As far as I know SYS/BIOS does only handle stuff inside a CorePac. I've never found any SYS/BIOS APIs which relate to any global peripherals on the SoC.

    So probably the CSL libraries are the only way to set registers residing outside of a CorePac