What causes NRF_ERROR_INTERNAL pstorage_clear callback

[John Chinnick]

Using nrf51822, Softdevice S110 V8.0 with SDK V8.0.

Sometimes after attempting to erase a pstorage page with pstorage_clear the firmware receives the NRF_ERROR_INTERNAL status code in the pstorage callback. Sometimes this occurs around the time that Bluetooth connections are changing state.

What is the recommended recovery method from this error condition? Is it expected that the application should just try the operation again, or is this an indication of a bigger problem?

[Susheel Nuguru]

This means that the softdevice was not able to allocate a time slot (22.3 ms) for the flash operation. This could happen if there is continuous BLE activity and the softdevice has reserved next cycle future timeslots to this BLE activity.

You do not need to recover from it, it just means that the operation the failure is from the softdevice and it couldn't start clear operation.

[John Chinnick]

OK, the application may need to retry erase operations, but it won't know until sometime after the pstorage_clear operation is queued up. Therefore one should not queue up pstorage operations after an erase operation that depend on the erase completing since the erase may fail and need to be retried which would also cause the subsequent pstorage operations to fail.

[Susheel Nuguru]

you cannot queue the pstorage operations, you should get NRF_ERROR_BUSY if you try to do so from pstorage. The reason for this is that because the pstorage operations are asynchronous, and the result will be known after sometime, if you queue the operations you would not know which operation failed and which one succeeded.

[John Chinnick]

The pstorage interface does allow queuing of commands (at least in V8.0 of the SDK). It does not return NRF_ERROR_BUSY unless the queue is full. Therefore, one has be be aware of these limitations if one chooses to use the queuing feature. Thanks.