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

[Menon]

Hello,

Could you please try testing with a lower QSPI frequency (e.g., 1–8 MHz) to see if this makes a difference? It also appears that the dedicated QSPI pins are not being used, which can sometimes lead to arbitrary bit flips. These issues may only become visible because the bootloader verifies large chunks of data. See the documentation here, and also on QSPI

When using non-recommended QSPI pins, you may need to adjust the qspi.rxdelay value and also use lower clock frequencies. Take a look at this devzone case as well.

As another check, you can read back the image from the QSPI flash after uploading it and compare it with the original binary. This will help confirm whether any data corruption is occurring. See programming the external memory.

Kind Regards,

Abhijith

[chodge]

Hi Abhijith,

Reducing the frequency to 2MHz didn't appear to help.

I did manually read back the contents of the flash, and doing some comparisons it appears that every 400 bytes is incorrect.  The first 3 bytes which don't match are at offsets 0x5A5, 0x9A5 and 0xDA5.  They also appear to be a single bit flipped, though not the same bit.  There are a total of ~500 bytes which are incorrect.

Hopefully that's a clue, but I'm not sure what it means.  But it appears to be systematic.  Any ideas?

Thanks,

Chris