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

[chodge]

Hi Abhijith,

MCUBOOT doesn't include any logs which indicate exactly where the error is, the logged error is on a higher level call which encompasses a lot of underlying checks.  I modified the MCUBOOT code to include print statements at each individual check, to identify exactly which one was failing.

This is the exact check which is failing, all of the validations to that point are successful.

Thanks,

Chris

[Menon]

Hello Chris,

Could you let me know which NCS version you are using here, or if you are working purely with Zephyr? Also, could you please share the generated partition file from the build folder?

Kind regards,
Abhijith

[chodge]

Hi,

This is NCS 2.6.4.  Here is the contents of the partitions file:

app:
  address: 0x16200
  end_address: 0xfe000
  region: flash_primary
  size: 0xe7e00
external_flash:
  address: 0xe8000
  end_address: 0x200000
  region: external_flash
  size: 0x118000
mcuboot:
  address: 0x0
  end_address: 0x16000
  region: flash_primary
  size: 0x16000
mcuboot_pad:
  address: 0x16000
  end_address: 0x16200
  placement:
    align:
      start: 0x1000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x16000
  end_address: 0xfe000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0xe8000
  span: *id001
mcuboot_primary_app:
  address: 0x16200
  end_address: 0xfe000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0xe7e00
  span: *id002
mcuboot_secondary:
  address: 0x0
  device: DT_CHOSEN(nordic_pm_ext_flash)
  end_address: 0xe8000
  placement:
    align:
      start: 0x4
  region: external_flash
  share_size:
  - mcuboot_primary
  size: 0xe8000
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

Thanks,

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