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,

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

[AHaug]

frankenboom said:

- 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?

If you have an external regulator, you would have to power this in the bootloader before you get access to the flash chip. I had a chat with one of our hardware engineers and we concluded we might need a schematic to answer this. Could you either upload it here if you're comfortable with uploading it publicly or create a new private case and refer to this case as a reference with the schematic?

Kind regards,
Andreas

[frankenboom]

Hi Andreas,

I can provide some snippets. Generally speaking, the regulator is always connected to the battery. The 3v3 rail is then enabled with a GPIO.

Here you can see REG_EN net (pulled down) connected to EN2, which controls OUT2, which is the 3v3 rail.

We are using a FANSTEL BC840M as the module. Pin 26 (on the NRF SOC) controls REG_EN.

Here is the flash chip. VCC pin is connected to 3V3 output of the regulator. Note that the pullups for CS, Write protect/IO2, and RESET/IO3 are connected to this same rail.

After a bit more digging, it sounds like a method mentioned in this ticket may he helpful?
devzone.nordicsemi.com/.../mcuboot-hold-gpio-on-boot

[frankenboom]

Update: adding CONFIG_REGULATOR=y to the mcuboot child image .conf appears to have fixed the issue with the flash chip not having power before communication is attempted - the board now boots without manual intervention.

It seems the remaining issue is to experiment with transitioning to QSPI.

[AHaug]

Hi,

Looks to me that CONFIG_REGULARTOR=y is what you needed. Glad to hear that!

W.r.t transitioning to QSPI, which GPIOs had you set your peripheral up to use? More specifically: which GPIOs are qspi_default and qspi_sleep set up to use through pinctrl-0 and 1?

Kind regards,
Andreas