Summary

The PYBD boards use an F7xx which has an errata 2.4.3:

Memory-mapped read operations may fail when timeout counter is enabled

This is unfortunate because it means that once QSPI memory-mapped flash is accessed the QSPI peripheral will leave the CS pin active (low) forever, which increases power consumption of the SPI flash chip (because it's active and waiting for commands). The exact amount of power increase depends on the flash, but the PYBD_SFx increase by about 2.5mA.

Previously this increase in power only happened when QSPI flash was needed, eg on PYBD_SF2 when mbedtls or nimble libraries were used. On PYBD_SF6 it's actually never used.

But with the introduction of ROMFS which lives in the QSPI flash, the memory is always access on start up to see if the ROMFS contains a valid image (it must read the memory to find out). That means these boards always consume about 2.5mA more after starting up.

The fix in this PR is to explicitly restart the QSPI memory mapped mode during the start up process. More precisely the restart is done after querying the ROMFS and just before trying to execute boot.py. That's the right location to keep power consumption permanently down if the QSPI is never used (eg ROMFS image doesn't exist).

Testing

Tested on PYBD_SF2 and PYBD_SF6.

It's possible to trigger the higher power consumption via machine.mem32[0x90000000] (or mpremote romfs query). Then get it back down again by doing a soft reset (or mpremote soft-reset).

Trade-offs and Alternatives

There could be a possible race condition if the QSPI memory is in use when it gets restarted. But I convinced myself that's not possible on PYBD_SFx because there should be no interrupts (or other user code at thread level) running during start up that accesses the QSPI mapped flash.

If a user has custom C code that does need QSPI memory mapped flash during start up, they can easily disable this restart feature by redefining MICROPY_BOARD_RUN_BOOT_PY.