NXP LPC55xxx and MCUBoot Support

[Phase777]

I am trying to build the smp_svr sample for the lpcxpresso55s36 board and am running into issues. In fact when I try to build the smp_srv sample for any board in the lpc55xxx series only the lpcxpresso55s69_cpu0 is successful. After digging into the board, SOC, and DTS folders for the lpcxpresso55s36 it appears that there are many things missing in order to build a project with MCUBoot/mcumgr, such as flash partitions and iap enabling. Was this done on purpose, with the intended approach of making the necessary changes in an overlay file in the project? Any instruction on how to build the smp_svr sample for lpcxpresso55s36 or add MCUBoot/mcumgr to a project targeting lpcxpresso55s36 would be helpful. Thanks.

[DerekSnell]

Edit: this comment is OUTDATED, see the newer comment below for the latest.

Hi @Phase777 ,

Please be aware that due to a current limitation in MCUboot not supporting large block size writes, MCUboot is not currently supported on the LPC55xx devices. See the discussion in this closed PR for more details #45526 (comment). Best regards

[irose-PeLtd]

@danieldegrasse , So for LPC55xx users is the preferred bootloader solution to use the NXP MCUBoot secondary bootloader? I see where the applications notes and code examples have been updated to support the LPC55XX processors.

For sake of clarity in this next comment, I am going to refer to the MCUBoot project as "MCUBoot", and the NXP MCUBoot code as "NXPBOOT". Otherwise, I tend to confuse myself.

At that point, would it be an option to override the MCUBoot calls to use the NXPBoot application code? Effectively using all the Zephyr tooling, but getting the functionality from the NXP code?

[DerekSnell]

Hi @irose-PeLtd ,

NXP MCUs integrate a bootloader in ROM, which offers secure firmware updates through the serial interfaces. If the ROM bootloader does not meet the needs for the use-case, as you found NXP also offers NXP's Secondary Bootloader (SBL). These are both good options on NXP MCUs, and fully supported by NXP. And as you found, the LPC55S69 platform is supported by SBL.

would it be an option to override the MCUBoot calls to use the NXPBoot application code? Effectively using all the Zephyr tooling, but getting the functionality from the NXP code?

That option does not sound trivial, and is not supported by anyone, so you would mainly be on your own. If you choose to use SBL, I recommend you use it as intended, to leverage NXP's support.

Best regards

[irose-PeLtd]

@DerekSnell ,

Thank you for your response.

As I work through this, the secondary bootloader I found the one at this link. https://www.nxp.com/docs/en/application-note/AN13497.pdf Which covers the LPC55S36.

The link you listed above takes me to a Secure Bootloader, which is for the LPC55S69.

It looks to me that the AN13497 is the best option. However, in the SW zip file that accompanies the app note, the boot loader folder does not contain an MCUXpresso project structure. The Application code included as an example, does include an MCUXpresso project. Am I missing something? Is the intent to create a project and import the bootloader code there?

[DerekSnell]

Hi @irose-PeLtd ,

This GitHub discussion forum is specific to Zephyr. Since your questions about the AN13497 bootloader are not related to Zephyr, I suggest you create a post at NXP's Community forum for LPC. That way, your question will be handled by the NXP engineers who support the LPC MCUs and this appnote. And I see it appears you already did created this post.

Best regards

[DerekSnell]

Hi @Phase777 and @irose-PeLtd ,
I am updating this discussion, as MCUboot is now supported on the LPC5500 devices.

However, there are limitations. The known limitation mcu-tools/mcuboot#713 is still present, because MCUboot does not support large flash page sizes for writes, and the LPC5500 devices exceed that limit with 512B page size. To work around this, MCUboot builds for LPC5500 by selecting CONFIG_BOOT_UPGRADE_ONLY=y. Therefore, MCUboot's SWAP mode is not supported, and MCUboot will not be able to recover to the previous firmware image. The application can download the new image to slot1 and confirm the image is valid. But when MCUboot performs the upgrade, the previous image in slot0 will be erased and replaced with the new image. When building an application, the following is added to enforce this:

CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS="--overwrite-only --align 8"

Best regards

[HyperionCoding]

Is this ever going to change or is it fundamental limitation of some sort?

[danieldegrasse]

A fundamental limitation (as I understand it) unfortunately- this has to do with how MCUBoot tracks the swap status of images while performing upgrades, which relies on the flash erase size being much large than the flash write size. In the future if a new method of tracking swap status was created, this limitation could be removed.