[NRF5340] HardFault when accessing application core memory from network core

Hello, we are using the NRF5340 with the new Zephyr SDK in our design and we are having issues reading the application core memory from the network core.
A read to any address in the application core RAM always results in a HardFault:

crashVal = *(uint32_t*)0x20010000;

CFSR after the HardFault:  0x00008200

Even though it shouldn't be necessary, we are setting NRF_DCNF->EXTRAM->PROTECT to 0 in the app core before starting the network core.

Is there any other register that needs to be set to allow this type of memory access from the network core?

Thank you

Parents
  • If you have a secure application core build, you must grant network core access using the following:

    NRF_SPU->EXTDOMAIN[0] = 0x12

    Note, this is already set in the nrf5340_cpunet_reset.c file that runs in the application core by default on bootup but the SDK has an undocumented bug that we've been hitting.  Currently it is NOT setting it correctly.  The default reset value of this register is 0x02, which means USER defined and controlled by BIT 4 of this register. However, the SDK board support files attempt to assign BIT 4 by doing NRF_SPU->EXTDOMAIN[0] = 1 << 4.  This is wrong because it clears BIT 1 when setting BIT 4, which changes it from user selectable to NON-SECURE.  This means that the network core presents itself as a non-secure bus master when attempting to read from secure accessible RAM.

    Without applying the above fix to the nrf5340_cpunet_reset.c in our BSP our custom boards will eventually lockup due to bt_enable calls being unable to reach the network core.  Debugging the network core shows that the RPMsg bring up code attempts to read IPC / OpenAmp status from 0x20070000 but gets a bus fault and hangs in the default fault handler.  This appears randomly after entering system OFF and waking our device but in some instances can happen to us after just 4 SYSTEM OFF cycles.  By setting the register as I've corrected it and applying errata 161 to wake the network core, I've been able to complete over 30 successful SYSTEM_OFF to ON transistions.

Reply
  • If you have a secure application core build, you must grant network core access using the following:

    NRF_SPU->EXTDOMAIN[0] = 0x12

    Note, this is already set in the nrf5340_cpunet_reset.c file that runs in the application core by default on bootup but the SDK has an undocumented bug that we've been hitting.  Currently it is NOT setting it correctly.  The default reset value of this register is 0x02, which means USER defined and controlled by BIT 4 of this register. However, the SDK board support files attempt to assign BIT 4 by doing NRF_SPU->EXTDOMAIN[0] = 1 << 4.  This is wrong because it clears BIT 1 when setting BIT 4, which changes it from user selectable to NON-SECURE.  This means that the network core presents itself as a non-secure bus master when attempting to read from secure accessible RAM.

    Without applying the above fix to the nrf5340_cpunet_reset.c in our BSP our custom boards will eventually lockup due to bt_enable calls being unable to reach the network core.  Debugging the network core shows that the RPMsg bring up code attempts to read IPC / OpenAmp status from 0x20070000 but gets a bus fault and hangs in the default fault handler.  This appears randomly after entering system OFF and waking our device but in some instances can happen to us after just 4 SYSTEM OFF cycles.  By setting the register as I've corrected it and applying errata 161 to wake the network core, I've been able to complete over 30 successful SYSTEM_OFF to ON transistions.

Children
No Data
Related