nrf5340 MCUBOOT fails with multi image build at 1.8.0

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Mon, 24 Jan 2022 15:26:01 GMT

I'm happy you got it to work!

Could you open a new ticket about the watchdog, since it's not related to the initial issue (bus fault at libmetal/libmetal/lib/io.c)?

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

mnvcsUDT — Mon, 24 Jan 2022 15:24:34 GMT

Is there any other way, the watchdog to be enabled?

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

mnvcsUDT — Mon, 24 Jan 2022 14:03:20 GMT

Hi Simon,

Sorry just missed the notification of your previous answer.

I managed to get it to work with the workaround. Just needed a clean build. Thank you!!

We do not need Zigbee FOTA so that part is fine.

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Mon, 24 Jan 2022 12:58:09 GMT

Have you tested the suggested workaround? Does it resolve the issue?

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Wed, 19 Jan 2022 22:12:01 GMT

A workaround for the issue is to set CONFIG_NRF53_UPGRADE_NETWORK_CORE=n in the prj.conf file (assuming you don't need to upgrade the Net Core application). I tested this with your sample and I no longer got the bus fault from modules/hal/libmetal/libmetal/lib/io.c. However, I had to comment out wdt_feed() and wdt_setup() in main.c, since it caused an Instruction bus error, but that's another issue.

We are working on a fix for the core of the issue and I will update this ticket when get more clarity.

You should be aware that we don't fully support Zigbee FOTA on the nRF53 yet. If you have questions about this or other future/road map related questions, contact the Regional Sales Manager in your area, if you don't know who this is, send me a PM.

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

mnvcsUDT — Wed, 19 Jan 2022 15:04:47 GMT

Thanks Simon, and also for the regular updates.

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Wed, 19 Jan 2022 14:34:04 GMT

Seems like this is a Zigbee-specific issue, since the rpmsg_nrf53_sram area only will be included when Bluetooth is used (bluetooth specific config BT_RPMSG_NRF53 needs to be enabled):

As I'm not very familiar with Zigbee, I have asked the Zigbee experts internally and waiting for an answer. I will keep you updated.

Best regards,

Simon

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Fri, 14 Jan 2022 15:11:31 GMT

I got some tips internally and did some investigations myself and got some progress.

During the zephyr kernel initialization process (before main), rpmsg_service_init() runs, which will eventually end up in /modules/hal/libmetal/libmetal/lib/io.c:134 and try to write to the address 0x2007fc00, which is a part of the pcd_sram, according to the ninja pm report:

+--------------------------------------------+
| 0x20000000: sram_primary (0x7e000 - 504kB) |
| 0x2007e000: pcd_sram (0x2000 - 8kB)        |
+--------------------------------------------+

The pcd_sram area is read-only after mcuboot has booted, see https://github.com/nrfconnect/sdk-mcuboot/blob/4e4e979c1998e6dad7e47011e6e076b861921645/boot/zephyr/main.c#L580. So that is why you're getting a bus fault

I looked in the file <sample>/build/zephyr/.config and saw these values

CONFIG_RPMSG_SERVICE_SHM_BASE_ADDRESS=0x20070000
CONFIG_RPMSG_SERVICE_SHM_SIZE=0x10000

which spans over the pcd_sram area.

I compared this to the peripheral_uart sample (with mcuboot enabled) and saw that it has the same values for RPMSG_SERVICE_SHM_BASE_ADDRESS and RPMSG_SERVICE_SHM_SIZE, but the ninja pm report looked like this:

+-----------------------------------------------+
| 0x20000000: sram_primary (0x6e000 - 440kB)    |
| 0x2006e000: pcd_sram (0x2000 - 8kB)           |
| 0x20070000: rpmsg_nrf53_sram (0x10000 - 64kB) |
+-----------------------------------------------+

and you can see it spans over the rpmsg_nrf53_sram (which is not present in your case) instead

I will continue the investigation on Monday and see how to fix this.

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Wed, 12 Jan 2022 13:42:20 GMT

Yes, I will let you know. Sorry for the delay on this, I've been quite busy lately. I have asked about this internally and currently waiting for a reply. I will keep you updated.

Best regards,

Simon

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

mnvcsUDT — Fri, 07 Jan 2022 10:55:27 GMT

Thank you Simon. Let me know if I can assist you.

Regards,

Milan

RE: nrf5340 MCUBOOT fails with multi image build at 1.8.0

Simon — Fri, 07 Jan 2022 10:01:23 GMT

Hello Milan,

This issue tricked me. I used quite long time debugging the mcuboot, thinking the issue happened there. But eventually I figured out that it actually successfully boots the main image. I ran the command addr2line -e zephyr.elf 0x4bdba (I got this log output: "<err> os: Faulting instruction address (r15/pc): 0x0004bdba") from <your project>/build/zephyr and got the following output:

/home/simon/ncs/modules/hal/libmetal/libmetal/lib/io.c:134

So I guess this happens during the Zephyr kernel initialization phase. I will continue to investigate this next week.

Best regards,

Simon