LPC55S69 Core1 security

[superliyou]

Dear  engineer，

        In  UM11126 I See below:

The LPC55S6x/LPC55S2x/LPC552x device includes a second instance of Cortex M33.
The configuration of this instance does not include MPU, FPU, DSP, ETM, Trustzone
(SECEXT), Secure Attribution Unit (SAU) or co-processor interface. It supports the same
debug levels and interrupt lines as the primary CPU.

       it means that core1  is not supported (ARMv8 m)Security extensions?  

       Core1 can only  access non secured address(Ram/flash)? 

       0x2000 0000 0x2000 FFFF 0x3000 0000 0x3000 FFFF SRAM 0 on CM33 data bus, 64 KB.

      These two addresses above physically point to the same block of ram?

       if SAU & IDAU set the ram above in secure region. Core1 can not accsee it?

thanks a lot!

[gusarambula]

Hello Superliyou,

That is correct, the second core (Core1) would be a coprocessor so it does not have its own Memory Protection Unit or Security Extension, all security options would be handled by the Core0, which manages the coprocessor trough the co-processor extensions.

The coprocessor access is controlled in the CPACR (Coprocessor Access Control Register), so you may enable secure access if you wish the coprocessor to be able to access secure regions.

I hope that this information helps!

Regards,
Gustavo

[superliyou]

Hi Gustavo，

    Thank you for your reply.

   If I use core1 as a stand-alone processor not a coprocessor for Core0. The only way for Core1 secure accsess control is by MASTER_SEC_LEVEL in AHB_Secure_CTRL Register? It also control the other master component's secure accesess on the chip like DMA? 

    And another reg MASTER_SEC_ANTI_POL_REG must config together?What does this mean? I'm a little confused about how to use it.  Just like below:

/* Security level configuration of masters */
AHB_SECURE_CTRL->MASTER_SEC_LEVEL = 0x80000000U;
AHB_SECURE_CTRL->MASTER_SEC_ANTI_POL_REG = 0xBFFFFFFFU;

    the high bytes of MASTER_SEC_ANTI_POL_REG is 10[bit31:30] , and the inversion is 01. it means the register can't be written (included this bitfield)? So the first reg 0x80000000 is write control,and the second reg write 0xBFFFFFFFU meas that it can no longer set unless you rest?

   This like OTP ? this is hardware mechanism guarantee?

[superliyou]

Waiting for reply......