What causes NRF_ERROR_BUSY responses from calls to the peer manager? (SDK v15.0.0)

[swlnk]

Device: nRF52832

SDK: v15.0.0

SoftDevice: S132 v6.0.0

The SDK v15.0.0 documentation for the peer manager states the following:

Autonomy: The Peer Manager works more autonomously than the Device Manager; for example, it automatically responds to security requests and has an in-built error recovery process. If the SoftDevice or the FDS reports a temporary failure, the Peer Manager will retry the calls and will report only permanent failures.

But for the pm_peer_rank_highest API function, I see the following mentioned as a possible return value:

* @retval NRF_ERROR_BUSY           If the underlying flash handler is busy with other flash
 *                                  operations, or if a previous call to this function has not
 *                                  completed. Try again after receiving a Peer Manager event.

Several other peer manager API functions also include NRF_ERROR_BUSY as a possible return value for similar reasons. This seems contradictory to the note about autonomy, as I would have thought that the flash being busy would count as a "temporary failure". It seems like my application now needs to keep track of whether the flash driver was busy or not and re-call the API later.

Is my understand of this correct? Do later versions of the SDK resolve this contradiction?

Thank you.

[Einar Thorsrud]

Hi,

I must admit that I had not noised the formulation in the peer manager documentation that you referred to before, but I agree that it is contradicting. I think the problem here is not primarily how the peer manager behaves, but that the documentation is misleading at this point. I will make an internal ticket requesting that the documentation is updated.

Regarding the actual behavior, instead of blocking when busy, the API will return NRF_ERROR_BUSY. This is the same for most libraries and drivers in the SDK. If the function you are calling can return NRF_ERROR_BUSY, then you should handle it. In practice this just means that you should try to call it again a bit later. You can see from the implementation in peer_data_storage.c that if an FDS call return FDS_ERR_BUSY, this will be propagated as NRF_ERROR_BUSY by the peer manager.

[swlnk]

Thanks for the response. Is this something that can be added to the peer manager in the future? I'm not suggesting that the API should be block if the flash driver is busy, but rather that the peer manager automatically retry at a later point in time instead of the application needing to set up retries.

[Einar Thorsrud]

I have added that request to the internal ticket. You should probably not expect this to be implemented in the peer manager soon, though.