Adding MCUBOOT and QSPI device to DTS causes no boot

[frankenboom]

I am attempting to get the SMP server sample to work on some custom hardware in order to run a BLE FOTA. I'm using NCS version 2.6.1.

I'm able to build the SMP server sample successfully using both versions of the custom hardware DTS.

When I comment out the QSPI device on the DTS file for the custom hardware, and flash the merged.hex file using the debugger, the bootloader and application both work as expected. Uploading a new image and testing/confirming also works as expected, with the new firmware running.

However, adding the QSPI device to the DTS causes the same process to fail - flashing merged.hex using the debugger seems to result in no boot. I tried reviewing the partition manager section in the FOTA devacademy lesson, but I'm still not sure what the issue is here.

Attached are the two DTS files. The v5_0_test_board.dts is the one that works and has some sections commented. the v5_0_prod_board.dts has these sections uncommented. The setting for the Winbond flash chip use some of the defaults from the mxr flash chip that comes on the devkit - these are eventually going to be corrected, but I don't believe they should affect anything until mcuboot tries to store an image on the external flash, is this correct?

Thanks in advance for the help.

v5_0_prod_board.dtsv5_0_test_board.dts

[AHaug]

Hi,

Could you also upload build logs (to see if there's any warnings that should not be ignored) and device logs (preferably with logs from both the bootloader and app even though I don't expect to see any logs from the app)?

Attached are the two DTS files. The v5_0_test_board.dts is the one that works and has some sections commented. the v5_0_prod_board.dts has these sections uncommented.

Am I looking in the wrong place w.r.t the commented/uncommented differences in the two files you've uploaded? Or your statement w.r.t what parts are commented/uncommented are not related to the qspi device?

Kind regards,
Andreas

[frankenboom]

Hi Andreas, thanks for the reply.

I should have clarified - the sections in the linked DTS files are where I believe the partitions are being declared on the external device. See the screenshot. 

I've narrowed down the problem further, though. Using the DTS file named v5_0_prod_board_narrowed.dts in the zip below, the no-boot condition occurs when the line
"nordic,pm-ext-flash = &w_25" is not commented. Commenting this line allows the application and bootloader to work as expected.

Attached are the build logs using these two variations of the DTS file, named accordingly.

As for the device logs, the non-boot case does not generate any output over RTT. Also, the working case does not appear to generate any bootloader output over RTT. I added some device logs from the working sample - I added the "test6" print statement to the default app.

I also attached some build output files, related to the configuration and the partition manager. There are significant differences in the partitions.yml files.
ext_flash_comment.zip

[AHaug]

Hi,

I've spent some time looking into this and I do believe that the issue might lie with this:

The setting for the Winbond flash chip use some of the defaults from the mxr flash chip that comes on the devkit - these are eventually going to be corrected, but I don't believe they should affect anything until mcuboot tries to store an image on the external flash, is this correct?

After discussing this question, initialization of some peripherals do occur during bootup, so the fact that you don't get to bootup with the wrongly configured Winbond flash might cause your app to get stuck there during initialization.

I suggest you exclude this reason before we move into spotting the difference between the two confiugrations 

1. Check your firmware with a nRF5340DK using the mx25 and see if you get past boot?
   1. If this fails, could you check with bootup with a minimal sample that uses your configuration?
   2. If this succeeds, could you try to define the Winbond device with the correct parameters, if you've not done that already since you raised the ticket?

Let me know if this is something that works for you

Kind regards,
Andreas

[frankenboom]

Hi Andreas,

Thanks for pointing me in the right direction. It does appear that any error with reading the JEDEC ID of the flash chip while in bootloader will cause the bootloader not to jump to app. Here are some of the things I have done:

- Added configurations to the mcuboot child image configuration to enable the clock from the internal RC oscillator instead of an external crystal which my custom HW does not have. These configurations were enabled in the main application configuration but I did not realize the same would need to be configured for the child image, which makes sense in hindsight.

- Used the JESD216 sample to read out the correct JEDEC ID and SFDP array. These have been added to the updated DTS. I've confirmed as well that these settings in the DTS are working correctly with the chip (I set CONFIG_SPI_NOR_SFDP_DEVICETREE=Y)

- Transitioned the driver for the external flash in the DT back to normal SPI, for two reasons:
-- The compatible "nordic,qspi-nor: does not have a vin-supply property. The flash chip is powered by a regulator which must be switched on prior to any flash transactions.
-- The flash chip I'm using will switch the functionality of one pin from HOLD or RESET to IO3 when configured with a certain register to use QSPI instead of the default SPI. I'm not sure whether the QSPI driver is able to account for this, so to be sure I eliminated this as a variable. I assume if this register is not configured, any attempt at a transaction that would switch the state of this pin would result in the chip being reset / blocked for further transactions. Can you point me to where I can edit the driver for the flash chip if this functionality is not added by default?

- I must reset the board while manually applying voltage to the rail powering the flash chip - it appears that, even though the vin-supply is added to the DT, whatever driver(?) is active in the bootloader does NOT enable the regulator. I consistently need to manually apply power to the flash chip's VDD in order for the application to run. Is there a way to make sure that the bootloader enables the regulator before attempting any flash transactions? What about for the QSPI driver, which does not have this property?

- Added some of the configuration options from this forum post to enable OTA with SPI instead of QSPI. Also, trying to enable the configuration option CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y seems to require that a QSPI device be present in the DTS to build successfully, so I manually ported over some of the config options from the SMP_SVR sample.

With the above changes, I'm able to run a full FOTA over BLE on my custom hardware, but still need help on the open questions. Also, in general, sifting through all the config options and their possible impacts on other config options and other application code seems opaque and difficult to disentangle.

[AHaug]

Hi,

frankenboom said:

Can you point me to where I can edit the driver for the flash chip if this functionality is not added by default?

For your first question you should be able to add this here: https://github.com/nrfconnect/sdk-zephyr/blob/baa4ee7ebd5d885119d6d196d62c1ca1e6af5841/drivers/flash/nrf_qspi_nor.c but I have some doubts w.r.t the support for changing qspi pins during runtime in Zephyr RTOS

frankenboom said:

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y seems to require that a QSPI device be present in the DTS

Yes, atleast previously this config implied (harder than select) that the QSPI driver should be enabled and a QSPI device is what that should've been used. I don't see the imply now in 2.8.0, but it's still designed around a QSPI device. The approach you mention with using configurations in smp_svr is what I would recommend you do, and if you get stuck have a look at any nRF91-based DFU samples or nRF7002DK (7002 + 5340) which uses SPI to communicate with the external flash.

frankenboom said:

Is there a way to make sure that the bootloader enables the regulator before attempting any flash transactions? What about for the QSPI driver, which does not have this property?

I will have to ask the devs about this to see if I can find someone who has an answer. I will get back to you

Kind regards,
Andreas