nRF53 network core bootloader fails to start because ACL full

[Stephan Walter]

We are using nRF5340 engineering D revision.

The software is nRF Connect SDK 1.7.0

We are seeing a problem with the network core bootloader (aka netboot, aka b0n)

Sometimes the bootloader fails to start the network core application.

We have enabled logging in the bootloader, then we see the following error message:

Failed to protect b0n flash, cancel startup

Looking into nrf\samples\nrf5340\netboot\src\main.c, we see that the bootloader tries to lock the flash using the ACL peripheral.

This fails because apparently the ACL list is not cleared on reboot. The function find_free_region then returns an error.

We reboot the chip using the shell command kernel reboot cold on the application core, which should also reset the network core according to the specification.

Is this a known hardware issue, or are we doing something wrong in software?

[Simon]

This is an issue I have not seen before and not familiar with. Would you be able to provide a detailed description how to reproduce it (upload a simplified sample if necessary)?

[Stephan Walter]

Hi Simon,

I tried to reproduce the issue using the PCA10095. Unfortunately I only have a version 0.8.0 with engineering revision A here, which I can't get to work with the SDK version 1.7.0

However, it should be possible to reproduce the issue as follows:

Use a convenient sample from nrf/samples/bluetooth or zephyr/samples/bluetooth

Modify the configuration to enable mcuboot and shell:

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_SHELL=y

This then causes b0n to be built for the network core.

Then, using a terminal program, issue the shell command kernel reboot cold several times.

The network core bootloader uses two ACL entries and the list has 8 available entries, so the list would overflow after 4 reboots.

In the failure case, the network core application firmware is not started, and therefore the rpmsg endpoint will not be ready for the application core to communicate with it. Depending on the sample project, the symptoms may vary, but I would expect a call to bt_enable to block.

I'll see if I can get a dev kit with a newer revision of the nRF53. In the meantime I hope this description helps you to reproduce the issue.

Best regards,
Stephan Walter

P.S: I now see that it is not so easy to reproduce with a sample, and our application is quite heavily modified (we have adapted the board configuration for our custom hardware). But the issue is reproducible consistently, so I'm looking into finding the crucial difference.

[Stephan Walter]

I have now tried an nrf sample on both the nRF5340DK (version 0.11.0 with engineering revision D) and on our custom board, modifying it only with regards to UART pinout. The difference in behaviour persists.

The chip on the nRF5340DK, which resets the ACL as expected, has the following information:

CONFIGID 000001f2
DEVICEID 8bf28b0b aaf1ea1a
VARIANT  514b4141

The chip on our application board, which fails to reset the ACL, has the following information:

CONFIGID 000001f6
DEVICEID d8041929 dc85c3cb
VARIANT  514b4141

We have seen the issue with more than one chip, so I don't think it's a defective unit.

Note that if CONFIG_RESET_ON_FATAL_ERROR is enabled for the network core bootloader, the issue may be less visible, as the bootloader failing to load the application causes a core fault, which then properly resets the ACL.

[Stephan Walter]

Hi Simon,

I got an email notification but I'm not seeing your reply here. You say that you can't reproduce the issue with nRF5340 DK v0.11.0. We agree on that.

The problem does occur with a chip that has a different INFO.CONFIGID in FICR. Does that mean that there are differences in the dies, despite both being revision D?

[Simon]

I deleted the reply, because I read your replies too fast, and gave a nonsensical answer, but yes, I was not able to reproduce it using an nRF5340 DK.

I'm not sure why you're seeing the different behavior between the chips. I have forwarded this internally, and will keep you updated if I get any inputs.