NRF54LM20 - NRF_MPC Alignment Assertion When Building With TFM And CONFIG_DEBUG

[ashlin4010]

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 0x2007FC00 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]

Hi ashlin4010,

I will need some time to look into this. I will follow up with you in 1-3 business days.

Hieu

[Hieu]

Hi ashlin4010,

Thank you for your patience. We confirm that this is a known issue and has already registered it in our backlog for fixing.

I am puzzled by your comment that fixing with a pm_static.yml file didn't work though. I find PM working as it should. Could you please share the pristine build log, pm_static file, and compiled partitions.yml? I would like to reproduce it and check.

Hieu

[ashlin4010]

As far as I am aware, the issues I have with the PM is expected but it is as follows:

If you make a build without pm_static.yml the output build/partitions.yml is whatever PM wants to do.

If you copy build/partitions.yml to pm_static.yml then update pm_static.yml, on the next build PM will take pm_static.yml as a suggestion only, and do its own thing. The output will only partially be based on pm_static.yml.

In this case I updated sram_nonsecure and sram_primary to be 4k aligned. But, once built only sram_nonsecure retained my changes. As far as I know there is no way to have a truly static pm_static file.

I have attached a zip with some files for examples:
- debug_partitions.yml - Output from a clean build, no pm_static.yml
- pm_static_nrf54lm20dk_nrf54lm20a_cpuapp_ns.yml - Updated from partitions.yml with 4k alignment
- final_partitions.yml - The out from the build when using pm_static.yml
I was building blinky and my pm_static.yml was named pm_static_nrf54lm20dk_nrf54lm20a_cpuapp_ns.yml

If you have any comment on reason behind this I would like to know, and workarounds.

The NS target on the nrf54lm20 is very new, so I don't expect it to be ready to use, so I am not bothered by its issues. But I am bothered by NRFX_ASSERT being disabled by CONFIG_DEBUG=n.

I would appreciate if you could look into my original questions. For example if I have CONFIG_DEBUG=n to save on rom sapce (might be testing on the nrf54l15), what other critical assets may I miss?

PM and NRFX_ASSERT might be better discussed in new tickets, if there is more to be said on the topic.

Thanks

/cfs-file/__key/communityserver-discussions-components-files/4/nrf54_5F00_ns_5F00_partitions.zip

[Hieu]

Hi ashlin4010,

ashlin4010 said:

I have attached a zip with some files for examples:
- debug_partitions.yml - Output from a clean build, no pm_static.yml
- pm_static_nrf54lm20dk_nrf54lm20a_cpuapp_ns.yml - Updated from partitions.yml with 4k alignment
- final_partitions.yml - The out from the build when using pm_static.yml
I was building blinky and my pm_static.yml was named pm_static_nrf54lm20dk_nrf54lm20a_cpuapp_ns.yml

If you have any comment on reason behind this I would like to know, and workarounds.

Thank you for the file. I have reproduced your observation now.

It seems that sram_primary is one of the few special cases that the Partition Manager doesn't take input from pm_static.yml. For sram_primary, the size is configured by the Kconfig CONFIG_PM_SRAM_SIZE instead.

And CONFIG_PM_SRAM_SIZE is set by default to 0x7fc00 for the nRF54LM20A.

I can see how this is not really user friendly. We will address this in a future release.

ashlin4010 said:

I would appreciate if you could look into my original questions. For example if I have CONFIG_DEBUG=n to save on rom sapce (might be testing on the nrf54l15), what other critical assets may I miss?

PM and NRFX_ASSERT might be better discussed in new tickets, if there is more to be said on the topic.

It looks like that this is because assert in general is disabled by default in the SDK. If you want to watch out for asserts, you can reenable them with CONFIG_ASSERT=y.

Regards,

Hieu

[ashlin4010]

Hieu said:

If you want to watch out for asserts, you can reenable them with CONFIG_ASSERT=y.

CONFIG_ASSERT=y has no effect on NRFX_ASSERT.

During development I always have a block like this:

################################################################################
# Debugging, Asserts and Safety
################################################################################
CONFIG_ASSERT=y
CONFIG_ASSERT_VERBOSE=y
CONFIG_EXCEPTION_DEBUG=y
CONFIG_EXTRA_EXCEPTION_INFO=y
CONFIG_ASSERT_LEVEL=2
CONFIG_THREAD_STACK_INFO=y
CONFIG_STACK_USAGE=y
CONFIG_HW_STACK_PROTECTION=y

It does not enable NRFX_ASSERT, only CONFIG_DEBUG=y enables it.

[Hieu]

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.