MCUBoot fails to initiate external memory driver

[kartapusse]

Hi,

I am developing on NRF5340 chip, using an external Flash memory (AT25SL321) on my custom board.

I was previously using vanilla Zephyr version 3.1.0 (everything was working perfectly) but I want to move on NCS version 2.6.0.

In order to perform a first test with NCS, I took exercise 3 from lesson 8 in Nordic Dev Academy (performing DFU over BLE):
 - If I am using a custom pm_static.yml file in order to put updates in internal memory, everything is fine. Moreover, my application itself is able to access to external memory.
 - If I am using default partitioning in order to put updates in external memory, MCUBoot fails to initiate external memory driver because JDEC-ID reading returns 00 00 00.

My board DTS definition is the same between my application and MCUBoot, so why MCUBoot is not able to access to my external memory ?

Could you please help me to solve this issue ?

[kartapusse]

Unfortunately, using SDK v2.6.1 does not improve the situation.

[Vidar Berg]

Thanks for confirming. Then we can exclude that issue, at least. Please try the project below and see if it is able to boot with your external flash device.

smp_svr_ext_flash_test.zip

[kartapusse]

I have exactly the same issue. I fall in FIH_PANIC (line 2324 of loader.c).

I put a breakpoint in qspi_init function of nrf_qspi_nor.c and I still have 00 00 00 when reading JEDEC id instead of expected value.

I am very confused because in my application sample JEDEC id is correctly read and I can access to the memory.

[Vidar Berg]

Yes, it seems strange that the application is able to read the JDEC ID but not the bootloader. They are both using the same driver. Is the ext. flash IC power-cycled through a reset, or does it remain powered? 

[kartapusse]

External Flash is powered through a ldo which is a fixed regulator.

I have a first issue with driver initialization default priority:

• CONFIG_REGULATOR_FIXED_INIT_PRIORITY is set to 75 by default
• CONFIG_NORDIC_QSPI_NOR_INIT_PRIORITY is set to 41 by default

This means that my ldo is initialized too late. And this explains why my application is able to access to the external memory (ldo is already activated by mcuboot when my application starts).

So I changed the mcuboot.conf by adding:

CONFIG_NORDIC_QSPI_NOR_INIT_PRIORITY=76

However, even with this modification, the issue was still there.

So I performed some debugging during regulator fixed driver initialization and I saw that startup-delay-us defined in my ldo was not used.

As mcuboot was working with Zephyr 3.1.0, I analyzed commits on regulator_fixed.c and regulator_common.c and I saw that there was some modifications related to startup-delay-us and this explains why mcuboot was working with Zephyr 3.1.0.

To validate this finding, I added the following piece of code after line 75 of regulator_common.c:

regulator_delay(config->startup_delay_us);

Finally, with the new priority for flash driver and adding the regulator delay, mcuboot is now able to access to my external memory.

However, this raises questions:

• Do I have an issue in my dts ? Should I specify the startup delay using another property ?
• I am not sure but I think there might be an issue in regulator_common.c: for instance, I think that it is not possible to enter in the else if ((config->flags & REGULATOR_INIT_ENABLED) != 0U) { statement