Adding MCUBOOT and QSPI device to DTS causes no boot

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

AHaug — Mon, 16 Dec 2024 10:04:10 GMT

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

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

frankenboom — Fri, 13 Dec 2024 10:27:13 GMT

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.

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

frankenboom — Fri, 13 Dec 2024 10:12:56 GMT

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

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

AHaug — Tue, 10 Dec 2024 09:12:16 GMT

[quote user="frankenboom"]- 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?[/quote]

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

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

AHaug — Mon, 09 Dec 2024 15:22:53 GMT

Hi,

[quote user="frankenboom"] Can you point me to where I can edit the driver for the flash chip if this functionality is not added by default?[/quote]

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

[quote user="frankenboom"]CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y seems to require that a QSPI device be present in the DTS[/quote]

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.

[quote user="frankenboom"]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?[/quote]

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

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

frankenboom — Mon, 09 Dec 2024 02:30:41 GMT

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.

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

AHaug — Thu, 05 Dec 2024 09:37:49 GMT

Hi,

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

[quote user=""]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?[/quote]

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

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

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

frankenboom — Mon, 02 Dec 2024 02:06:43 GMT

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.
devzone.nordicsemi.com/.../ext_5F00_flash_5F00_comment.zip

RE: Adding MCUBOOT and QSPI device to DTS causes no boot

AHaug — Tue, 26 Nov 2024 13:07:08 GMT

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

[quote user=""]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.[/quote]

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