Inconsistent QSPI flash behavior between APP and MCUBOOT

[chodge]

It seems that I'm getting different results reading QSPI flash from the APP vs MCUBOOT, with the exact same configuration. Writes appear to work fine from either, but MCUBOOT isn't able to read the flash, whereas the APP can.

Initially I was trying to track down why uploaded DFU images weren't able to be validated by MCUBOOT, which looks like this:

I'm starting to think it's because MCUBOOT isn't properly reading the image from flash.  I am able to upload images via SERIAL directly to MCUBOOT, or via BLE to MCUMGR in the APP.  In either case, I am able to see the uploaded image through MCUMGR from the APP, but neither shows up in the image list when accessing from MCUBOOT, see example:

Initial image list from BLE (APP/MCUMgr):

Initial image list from SERIAL (MCUBOOT):

Upload image 105CFF via BLE and see it was uploaded to slot 1:

Image list with both images uploaded via SERIAL:

Upload image 777E0 via SERIAL ,and view the image list:

View the image list via BLE and see slot 1 was in fact replaced with 777E0:

The DTS is identical for both applications.  Here is the PM config:

app:
  address: 0x12200
  end_address: 0xfe000
  region: flash_primary
  size: 0xebe00
external_flash:
  address: 0xec000
  end_address: 0x400000
  region: external_flash
  size: 0x314000
mcuboot:
  address: 0x0
  end_address: 0x12000
  region: flash_primary
  size: 0x12000
mcuboot_pad:
  address: 0x12000
  end_address: 0x12200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x12000
  end_address: 0xfe000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0xec000
  span: *id001
mcuboot_primary_app:
  address: 0x12200
  end_address: 0xfe000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xebe00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xec000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xec000
settings_storage:
  address: 0xfe000
  end_address: 0x100000
  placement:
    align:
      start: 0x1000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x20040000
  region: sram_primary
  size: 0x40000

Any ideas?  Thank you!

Chris

[Sigurd Hellesvik]

Hi Chris,

What do you mean "both applications"?
Do you build MCUboot and the application separatley?

Also, what version of the SDK do you use?

Regards,
Sigurd Hellesvik

[chodge]

There is only one build.  I mean the top-level DTS and the one under child_image.

This is using 2.6.4.

Thanks,

Chris

[chodge]

Hi Sigurd,

I just want to be sure I was able to provide everything you need.  Please let me know if there's anything else and if you get a chance to review the configs.

Thanks,

Chris

[Sigurd Hellesvik]

The sck-frequency is off-by-one between MCUboot (right) and app (left):

I assume that little of a difference will not cause this issue, but it is worth checking.

Also, try to enable gpio0 for MCUboot:

If the above "shots-in-the-dark" does not work:
The error log is from here. 

Can you add logs to above this wherever fih_rc is set? For example here.
Then go into the function where the error comes from and add more logs to find out exactly what fails. For example here.
If we can track down exactly from where the error is returned, it can help us find how to fix it.
Specifically, I try to verify the assumption that MCUboot cannot find external flash. (In other cases I have seen where MCUboot cannot find external flash, it is something obvious missing from DTS or Kconfig, which is not the case here)

[chodge]

Hi Sigurd,

The off-by-one is interesting, because in the overlays both values are set in decimal to 104000000, I'm not sure why the hex in the final DTS would be different?

I did previously try enabling gpio0 just to see if it would help, it was one of the only differences I could find, but it didn't seem to make any difference.

I also previously did what you suggested, adding debug lines to the mcuboot loader, to see where the 'invalid' image message was coming from.  I concluded it was coming from `bootutil_img_validate()`.  That's about the point where I gave up and asked for help.

If necessary, I can go one level deeper into `bootutil_img_validate()` to determine which function inside there is failing, but I didn't go further since I didn't really understand the checks beyond that point.

Thanks,

Chris

[Sigurd Hellesvik]

chodge said:

I concluded it was coming from `bootutil_img_validate()

In this case, I think that MCUboot is able to read from the external flash, but that the data after the swap somehow is wrong.

Have you tried to write and read data to the external flash from an application to verify that you read the same that you wrote?

Try to run the JESD216 sample  on your external flash to make sure you got the right DTS configuration for it.

chodge said:

If necessary, I can go one level deeper into `bootutil_img_validate()` to determine which function inside there is failing, but I didn't go further since I didn't really understand the checks beyond that point.

Can you do that? Hopefully, I will be able to make sense of the issue.

[chodge]

Here is the check that fails.

I haven't explicitly tried to write/read data for comparison.  But I believe that functionality is being confirmed by the fact that I can upload an image via mcumgr, and then query the images and confirm the hash being read from the image is accurate.

I will confirm the configuration using the JESD216 sample as well, but hopefully knowing where the image validation is failing will give you an idea what's happening.

Thanks,

Chris