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.