Flash nRF7002 ROM patch via external SPI flash

[Daniel K]

I have been using the nRF7002 DK board; the nRF7002 uses the QSPI bus and the external NOR flash uses SPI.

The nRF WiFi driver's HAL and interface functions all require that the external firmware be accessible via the address bus, which means it can only be loaded from SRAM or over QSPI with XIP enabled.  This eats up >70KB of code space when built internally, and I'd like to free up more.

I would like there to be a method to update the ROM patch via the flash_map API, or via an externally-supplied interface that supplies a read function.

At one point I tried to switch the QSPI and SPI buses, because I think 2 lane QSPI should work, but it did not (probing the signals I may have bricked the SPI flash on one of my boards, and I abandoned attempts at switching the buses after that).

To override this functionality is very difficult, I have to edit the ..__nrf__drivers__wifi__nrf700x library target in CMake:

• Add a new choice option to NRF_WIFI_PATCHES_EXT_FLASH_SUPPORT to avoid having the patch added by the linker
• Remove src/fw_load.c and /nrfxlib/nrf_wifi_hw_if/hal/src/hal_fw_patch_loader.c
• Copy functions hal_fw_patch_chunk_load() and nrf_wifi_hal_fw_patch_boot()
• Supply alternate implementations of nrf_wifi_fw_load() and nrf_wifi_hal_fw_patch_load()

This is not an ideal solution by any means...  I do not like having to dig so deep into Nordic's library to make changes, and I would rather such change be supported by the NCS SDK to avoid breaking on future update.

[Daniel K]

I think enabling this option is not going to be simple; when I force it on, I get this error:

-- nRF WiFi FW patch binary will be stored in external flash
CMake Error at D:/Projects/nrf_sdk/v2.6.0/nrf/drivers/wifi/nrf700x/CMakeLists.txt:167 (message):
  Unable to find XIP area in dts
  

So this means the build system is still assuming it is a QSPI peripheral with XIP.

[AHaug]

Daniel K said:

IMO the help text on this should just state that it requires custom flashing support to write the firmware, or have another config switch to control whether it is automatically flashed.

Both yes and no. The philosophy is that the configuration documentation should only contain the most necessary information (which it does with !nRF7002DK), and that you should refer to the nRF7002DK regarding why (no QSPI in between external flash and nRF5340). But I agree that it is hard to find out why it is this way (I had to spend some time myself) and that it should be some other help text regarding programming firmware to external flash through spi and not qspi.

Daniel K said:

I hope that when NRFJPROG-157 is implemented, it does not interfere with that.

I've queried the discussion in NRFJPROG-157 for a status regarding it's priority. To my knowledge it should not interfere with this, as it's no problem use an external flash with SPI normally. It is just this part regarding the firmware patch relocation through the linker and programming through nrfjprog that interfers with this.

I'll get back to you with some more information regarding NRFJPROG-157 when I have some more constructive regarding this

Kind regards,
Andreas