Failed to open flash area ID 2 (image 0 slot 1): -19, cannot continue

[amirl]

Hello,

We're seeing an error that only happens after a cold reboot (unplugging the battery and replugging it) and it happens inside the bootloader while trying to open the secondary flash area in the external flash. I think. If I change the bootloader code inside `bootloader/mcuboot/boot/bootutil/src/loader.c` to reset Nordic instead of panicking, it's recovering fine (i.e. calling NVIC_SystemReset() instead of FIH_PANIC)

I'm using w25q64 for flash and QSPI to communicate with the flash.

The error message is:

E: Failed to open flash area ID 2 (image 0 slot 1): -19, cannot continue

I'm using the following DTS overlay:

/ {
 chosen {
 nordic,pm-ext-flash = &w25q64;
 };
};

&qspi {
 status = "okay";
 pinctrl-0 = <&qspi_default>;
 pinctrl-1 = <&qspi_sleep>;
 pinctrl-names = "default", "sleep";
 w25q64: w25q6435f@0 {
   compatible = "nordic,qspi-nor";
   reg = <0>;
   sck-frequency = <8000000>;
   jedec-id = [ef 40 17];
   sfdp-bfp = [
     e5 20 f9 ff ff ff ff 03 44 eb 08 6b 08 3b 42 bb
     fe ff ff ff ff ff 00 00 ff ff 40 eb 0c 20 0f 52
     10 d8 00 00 36 02 a6 00 82 ea 14 c4 e9 63 76 33
     7a 75 7a 75 f7 a2 d5 5c 19 f7 4d ff e9 30 f8 80
   ];
   size = <67108864>;
   has-dpd;
   t-enter-dpd = <10000>;
   t-exit-dpd = <35000>;
 };
};

Any pointers would be much appreciated.

[Kazi Afroza Sultana]

You can add a delay at the beginning of the qspi_nor_init() function to test if the flash IC needed more time to power up.

static int qspi_nor_init(const struct device *dev)
{
  const struct qspi_nor_config *dev_config = dev->config;
  int rc;

 

  // Test: give the flash IC more time to power up
  k_busy_wait(1000*100);

[amirl]

Unfortunately the qspi_nor_init method appears to be called after flash_area_open is called in loader.c. So it doesn't solve the issue

[Vidar Berg]

Sorry, I forgot that you already had a workaround in place when I responded. I agree that your approach is easier and is probably a better solution.

amirl said:

Come to think about it, if we only enable the power in our main code, after the bootloader, i'm not that certain why this fixes our issue if it's related to power.

If there is a mechanism that enables power to the flash from the nRF53 (e.g., turning on a regulator switch with a gpio output), then this mechanism must also be enabled in the bootloader to explain the behavior you are observing. Otherwise, I would have expected the flash IC to have remained off after the reboot and just triggered the FIH_PANIC again.

[amirl]

My thoughts exactly, however we are not turning on that regulator in the bootloader - it's primarily done in our main Nordic code after the bootloader finished

[Vidar Berg]

Sorry, but how is the bootloader expected to use the flash if it is not turned on until after the main app has started?

Edit: regarding the workaround, I’m worried the underlying issue can cause the the device to become bricked. E.g, if there is a power loss during DFU.

[amirl]

To be honest, I'm not certain. What I do know is that we turn on that regulator in main, after the bootloader finished.

I have the same fear regarding bricking. However, without this workaround, it's already bricked...

[Vidar Berg]

Can you not turn on the regulator in the bootloader instead?