(Q)SPI cleanup when using mcuboot

RE: (Q)SPI cleanup when using mcuboot

user16133 — Thu, 02 Jun 2022 12:17:47 GMT

No problem! Keep me in touch!

RE: (Q)SPI cleanup when using mcuboot

user75734 — Thu, 02 Jun 2022 11:47:02 GMT

Hi Giuliano

I'm not sure if the protected storage service will deinit the QSPI to be honest, and I'll have to ask internally. I'll also forward your suggestion as it might indeed be a good idea. Thanks!

Best regards,

Simon

RE: (Q)SPI cleanup when using mcuboot

user16133 — Wed, 01 Jun 2022 13:28:03 GMT

Hi,

It was just a suggestion, as one could expect that mcuboot would shut down all the resources it uses before jumping to the main application.

That would prevent some strange cases where some higher than expect current consumption can be observed when MCUBOOT is used in a sample that does not use QSPI itself. We've seen about a 2mA leakage because of that.

Now that I'm writing this answer, one special use case comes to mind: what would happen if the QSPI is only used in the secure part of an application with for example:

- TF-M using Protected Storage Service

- MCUBOOT

- Zephyr

The QSPI will reside only in the secure part to store the new firmware. MCUBOOT would leave QSPI ON, and the main application will not be able to shut it down (as the application will reside in the NS part).

Will the Protected Storage Service re-initialize the QSPI and put it to power down?

Giuliano

RE: (Q)SPI cleanup when using mcuboot

user75734 — Wed, 01 Jun 2022 13:14:53 GMT

Hi Giuliano

The QSPI cleanup is done in the QSPI Zephyr driver itself (...\ncs\vx.x.x\zephyr\drivers\flash\nrf_qspi_nor.c) instead of in the cleanup file to deal with erratum 122 in the nRF52840 for example. Do you mean that it rather should be put directly into MCUboot, if so why?

Best regards,

SImon