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]

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

[chodge]

I was able to run the JESD216 sample using my DTS.

p25q32h@0: SFDP v 1.0 AP ff with 2 PH
PH0: ff00 rev 1.0: 9 DW @ 30
Summary of BFP content:
DTR Clocking not supported
Addressing: 3-Byte only
4-KiBy erase: uniform
Support 1-1-1
Support 1-1-2: instr 3Bh, 0 mode clocks, 8 waits
Support 1-1-4: instr 6Bh, 0 mode clocks, 8 waits
Support 1-2-2: instr BBh, 4 mode clocks, 0 waits
Support 1-4-4: instr EBh, 2 mode clocks, 4 waits
Support 4-4-4: instr EBh, 2 mode clocks, 4 waits
Flash density: 4194304 bytes
ET1: instr 20h for 4096 By
ET2: instr 52h for 32768 By
ET3: instr D8h for 65536 By
size = <33554432>;
sfdp-bfp = [
        e5 20 f1 ff  ff ff ff 01  44 eb 08 6b  08 3b 80 bb
        fe ff ff ff  ff ff 00 ff  ff ff 44 eb  0c 20 0f 52
        10 d8 08 81
        ];
PH1: ff85 rev 1.0: 3 DW @ 60
sfdp-ff85 = [
        00 36 00 23  9e f9 77 64  d9 e8 ff ff
        ];
jedec-id = [85 60 16];

But the swap is still failing here.

[Sigurd Hellesvik]

The delay in answering here is due to limited staff during this period. I will try to get back to you in two or three weeks. Sorry for the inconvenience. 

[chodge]

Hi Sigurd,

Just checking in.  I know you're short staffed, but hoping I can get some suggestions soon.  Thanks again.

Chris

[chodge]

Hi Sigurd,

Any update you can provide on this?  Thank you!

Chris