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]

Hi,

Thanks for providing the build files. I have compared them but have not been able to spot anything obvious. When the JEDEC ID read from the chip does not match the ID defined in the devicetree, the QSPI driver will abort the initialization. This is why the bootloader reports -ENODEV (-19) when it later tries to access the secondary slot in external flash.

Is the Winbond connected directly to the same power rail as VDD from the nRF, or is it power gated? Also, I'm not sure why it would make any difference, but have you tried removing the 'sfdp-bfp' property from your w25q64 node?

Best regards,

Vidar

[amirl]

Our flash is on a separate rail from the Nordic and it not powered by the Nordic's VDD. It is powered by a 3.3V supply and a decoupling 0.1 µF capacitor is used to stabilize the voltage.

I tried to remove sfdp-bfp but it didn't make any difference.

[Vidar Berg]

Thanks for confirming. It still feels like it must be related to powering of the flash somehow - I can’t think of any other reasons for why it would work after a warm reboot, but not after a cold reboot. I realize it has been asked already, but still wondering if there may be any control signals to enable this rail, or if it turns on at the same time as when nRF is powered on. 

Is it possible to probe the supply pins on the chips with with a scope to troubleshoot this further?

A workaround to all this could be to patch the bootloader to allow it to boot the main app even if it fails to access the flash on startup assuming it will only happen after a cold boot. But it would be best if we could find the root cause.

[amirl]

Unfortunately it doesn't seem like we have an easy way of doing that. I believe that our current workaround is easier and less risky (see my very first message) 

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)

 

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.

[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?