• State Not Answered
  • Replies 48 replies
  • Subscribers 75 subscribers
  • Views 2327 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328653
Options

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.
Parents Reply
  • 0 in reply to amirl

    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

Children
  • 0 in reply to Vidar Berg

    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

  • 0 in reply to amirl

    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.

  • 0 in reply to Vidar Berg

    I am seeing this flag set in the generated config file

  • 0 in reply to amirl

    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.

Related