• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 123 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 289919
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

(Q)SPI cleanup when using mcuboot

user16133

Hi.

Is it possible to add SPI or QSPI cleanup once mcuboot is done?

I've checked nrf_cleanup.c, but it seems that (Q)SPI is not turned off, which increases the power consumption when the application starts if it does not use the external flash itself.


A simple hack is enable the (Q)SPI in the application, and put it to "power down", but could it be added directly to mcuboot?

Regards

Giuliano

Parents
  • 0

    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

Reply
  • 0

    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

Children
  • 0 in reply to user75734

    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

  • +1 in reply to user16133

    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

  • 0 in reply to user75734

    No problem! Keep me in touch!

Related
Terms of service