QSPI NOR power manager errrors when CONFIG_PM_DEVICE_RUNTIME is set

[Bogdan Marinescu]

I recently enabled power management in my code base by adding these two oiptions to my prj.conf:

CONFIG_PM_DEVICE=y

CONFIG_PM_DEVICE_RUNTIME=y

The code runs on an nRF5340 MCU with a LittleFS instance in an external MX25R64 QSPI flash. It all worked fine until I enabled the two options above in prj.conf, now I get this error each time the MCU starts:

<err> qspi_nor: pm_device_runtime_put failed: -16

It appears that things continue to work normally though, but I've yet to run extensive read/write tests on the external flash and the above error is a bit concerning. I also have 

CONFIG_NORDIC_QSPI_NOR_XIP=y in my prj.conf, which (among other things) is supposed to keep the external flash from sleeping if I understood correctly (I need this for various reasons). 

Does anybody know how concerned I should be about this error? Thank you.

EDIT: sorry, forgot to specify: I am using Nordic Connect SDK 2.7.0.

[Simonr]

Hi

Error message -16 points to the device or resource you're calling being busy, so it seems the QSPI is doing something when the pm_device_runtime_put() function is being called in your project. If you don't intend to suspend the device, like this function does, you should find out where and why it's being called, as something in your application is trying to put the device in a suspended state.

Best regards,

Simon

[Bogdan Marinescu]

Hi SImon,

Thabks for your reply. I agree with the first part of your answer: indeed, it seems like the QSPI NOR device is busy when pm_device_runtime_put is being called. However, I disagree with "something in your application is trying to put the device in a suspended state", because I don't do any explicit power management on the QSPI NOR in my application. And I don't think I should, because I believe that the QSPI NOR driver (and maybe some lower level drivers) should do this automatically. If my applcation should actually be involved in this process, please let me know how.

Thanks,
Bogdan

EDIT: also, remember what I said earlier: in my application, I don't actually want the QSPI NOR to go to sleep, which is why I set CONFIG_NORDIC_QSPI_NOR_XIP=y. It is my understanding that this configuration option should prevent the QSPI NOR from sleeping. If this is correct, then the driver shouldn't attempt to put it to sleep at all. 

[Simonr]

Hi

Okay, so I think what's happening here is that this error is caused because you've set CONFIG_NORDIC_QSPI_NOR_XIP=y in your project, because it will keep the QSPI busy to avoid it from being affected by the power management. But something in your project does use power management, that is in turn rejected by the QSPI. Are you trying to put the nRF53 to sleep at all, because that will also call the pm_device_runtime_put I believe.

Best regards,

Simon

[Bogdan Marinescu]

Hi SImon,

I am definitely not ttrying to put the MCU to sleep manually. When I enabled CONFIG_PM_DEVICE_RUNTIME, I added various calls to pm_device_runtime_get and pm_device_runtime_put in my code. With these changes in places, power management should be automatic: the PM subsystem should figure out which device(s) it can put to sleep and when (I am not considering device drivers here (which need to do more work), because my code doesn't implement any device drivers, it just uses the existing ones). However, none of the PM calls in my code touch the QSPI NOR device, I just use the existing driver. And the driver should do all the required PM work automatically. Looking at the driver, I don't think it's doing it correctly. I'm talking specifially about https://github.com/nrfconnect/sdk-zephyr/blob/v3.6.99-ncs2/drivers/flash/nrf_qspi_nor.c#L318-L323:

if (!dev_data->xip_enabled) {
    qspi_clock_div_change();

    pm_device_busy_set(dev);
}

I would think that you want to call pm_device_busy_set when XIP is enabled, not disabled, like the code above does? There might be other places where this isn't used correctly, I just highlighted one that looks suspicious.

Thanks,
Bogdan

[Simonr]

Hi Bogdan

So I double checked with the devs regarding this, and I'm told that yyou can safely ignore this error, as it is just the QSPI letting you know it can't be powered down because of XIP being enabled. If everything works as intended you should be just fine. They will also double check the driver to make sure it's working correctly, but at first glance it seems okay.

Best regards,

Simon