NRF54LM20 - NRF_MPC Alignment Assertion When Building With TFM And CONFIG_DEBUG

Question

Issue 
 When building the Blinky example for the NRF54LM20A with TFM and CONFIG_DEBUG=y the MCU will assert on boot. 
 When booting an assert is triggered in workspace/modules/hal/nordic/nrfx/hal/nrf_mpc.h 
 NRF_STATIC_INLINE void nrf_mpc_override_endaddr_set(NRF_MPC_Type * p_reg,
 uint8_t index,
 uint32_t address)
{
 NRFX_ASSERT(index < NRF_MPC_OVERRIDE_COUNT);
 NRFX_ASSERT((address & 0xFFFUL) == 0);

p_reg->OVERRIDE[index].ENDADDR = address;
}
 
 At some point the above function is called with the address 0x2007FC00 and triggers the assert. The address 0x 2007FC00 can be found in build/partitions.yml for both sram_nonsecure and sram_primary partitions. 
 Steps to Recreate 
 Added CONFIG_DEBUG=y to prj.conf, build (west build -b nrf54lm20dk/nrf54lm20a/cpuapp/ns --pristine) 
 Debugging I did try to override partitions.yml with pm_static_nrf54lm20dk_nrf54lm20a_cpuapp.yml by manually shrinking sram_nonsecure and sram_primary to meet the alignment requirements. This did not fully work, TFM got a little more into the boot preocess before asserting on some other issues. pm has a tendency to do its own thing even if you try override it with pm_static so I stopped there. 
 
 Checking things just now, the non-debug build also should have alignment issues but NRFX_ASSERT is disabled in non-debug builds. I think that is a bit of an issue , I don't know the function of the MPC, but I would assume it is important for security. I think the policy on the asserts in nrf_mpc need to be reevaluated. 
 Comnents The docs for CONFIG_DEBUG say this: Build a kernel suitable for debugging. Right now, this option only disables optimization, ... There is no mention that it will also disable some runtime assets nor can I find any Kconfig options to keep NRFX_ASSERT in the build. 
 Questions Where does pm get the base values for partion layout? How else can NDEBUG be enabled? 
 Environment Linux SDK 3.2.1 Toolchain 3.2.0 Thank you

Hieu · Accepted Answer

Hi ashlin4010, 
 I trace back the root cause to this point: https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/ncs-v3.2.0/platform/ext/target/nordic_nrf/common/core/common/nrfx_glue.h#L60-L64 
 I have also noted with our TF-M team to consider changing this implementation to take into account CONFIG_ASSERT as well. For what it's worth, they are very receptive to the idea and was surprised at the current state themselves. 
 As for your other question of whether there are any other asserts you are missing, I honestly am not sure. I tried to look into this by searching for #define.*assert in the entire SDK. I found that a lot of modules and libraries have their own approaches. While it isn't impossible to trace them to be sure if CONFIG_ASSERT affects them correctly, there are simply too many for me be able to answer in the scope of this ticket. 
 I know this isn't the answer you are looking for, and I know the basis is even weaker from what we have seen with TF-M's handling of NRFX_ASSERT, but I think we just have to have faith that the modules we are using implements ASSERT correctly, following Zephyr's approach, which is to refer to CONFIG_ASSERT.

NRF54LM20 - NRF_MPC Alignment Assertion When Building With TFM And CONFIG_DEBUG

Top Replies