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

[SJahnke]

Hi Kazi Afroza Sultana 

having the same issue. Any news on this?

[Kazi Afroza Sultana]

How does the FLASH IC remained power? 

[amirl]

Our flash chip is powered by a 3.3V supply and a decoupling 0.1 µF capacitor is used to stabilize the voltage. I believe that because our power supply is stable and active, the flash IC should remain powered on.

[Vidar Berg]

Hello,

Since you're only experiencing this after a cold reboot, it seems likely that the issue is due to the flash IC not having sufficient time to power up before qspi_nor_init() is called during startup in the bootloader. qspi_nor_init() is executed after the kernel is loaded but before the application starts. Therefore, this occurs before the functions in loader.c are invoked from bootloader main().

Here are the timing paramaters I found for a similar part number:

amirl said:

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

This should not be possible when using the SDK driver, as it is initialized before the application by the macro shown in the picture above. However, note that this function will be executed twice during boot: once when MCUBoot starts up, and a second time when the application starts.

Do you have logging capabilities on this device? In that case, you may consider enabling logging in the flash driver by adding CONFIG_FLASH_LOG_LEVEL_DBG=y to your mcuboot build.

Kazi Afroza Sultana said:

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.

Did you try adding this delay?

Best regards,

Vidar

[amirl]

Thanks Vidar.

My mcuboot build does enable CONFIG_FLASH_LOG_LEVEL_DBG, however I haven't seen anything useful other than what I have posted here.

I have added the delay in qspi_nor_init, but it didn't solve the issue.

I added warning prints before and after the delay to show when it is being called. Unless the log is printed out of order, it does look like qspi_nor_init is called after the code in loader.c.

Warm boot:
I: Starting bootloader
I: About to open flash area ID 4 (image 0 slot 0)
I: About to open flash area ID 2 (image 0 slot 1)
I: Image index: 0, Swap type: none
I: About to open flash area ID 1 (image 1 slot 0)
I: About to open flash area ID 8 (image 1 slot 1)
I: Image index: 1, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
I: Starting bootloader
I: About to open flash area ID 4 (image 0 slot 0)
I: About to open flash area ID 2 (image 0 slot 1)
I: Image index: 0, Swap type: none
I: About to open flash area ID 1 (image 1 slot 0)
I: About to open flash area ID 8 (image 1 slot 1)
I: Image index: 1, Swap type: none
I: Bootloader chainload address offset: 0x10000
I: Jumping to the first image slot
GW [00:00:00.001,098] <wrn> qspi_nor: Waiting...
GW [00:00:00.499,542] <wrn> qspi_nor: Done waiting...
GW [00:00:00.499,755] <dbg> qspi_nor: configure_chip: RDSR 00 QE 0 need 0: no-change

Cold boot:

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

[Vidar Berg]

Hi,

amirl said:

My mcuboot build does enable CONFIG_FLASH_LOG_LEVEL_DBG, however I haven't seen anything useful other than what I have posted here.

Please double-check that this symbol got selected in your mcuboot build by checking the generated config file (build/mcuboot/zephyr/.config).

amirl said:

I added warning prints before and after the delay to show when it is being called. Unless the log is printed out of order, it does look like qspi_nor_init is called after the code in loader.c.

The line 'GW [00:00:00.499,755] <dbg> qspi_nor: configure_chip: RDSR 00 QE 0 need 0: no-change' is printed by the application, not the bootloader.

There should have been a 'D: qspi_nor: configure_chip: RDSR 00 QE 0 need 0: no-change' message before the 'I: Starting bootloader' message if the CONFIG_FLASH_LOG_LEVEL_DBG setting is enabled in the bootloader.

[amirl]

I am seeing this flag set in the generated config file

[Vidar Berg]

Thanks for confirming. Are you using UART or RTT for logging? I'm trying to understand why you might be missing the logs from the QSPI NOR driver in the bootloader.

[amirl]

I'm using UART

[Vidar Berg]

Could you please try to add the following lines to your qspi_nor_init() function in ncs/zephyr/drivers/flash/nrf_qspi_nor.c file to see if you can get these messages in your log after a warm boot?

static int qspi_nor_init(const struct device *dev)
{
	const struct qspi_nor_config *dev_config = dev->config;
	int rc;
	/* Indicate if called from bootloader or app */
#if CONFIG_MCUBOOT
	LOG_ERR("QSPI NOR INIT in bootloader");
#else 
	LOG_ERR("QSPI NOR INIT in application");
#endif
	/* Delay startup */
	k_msleep(1000);
    
    ...