PStorage Event Handler Problems

[ChrisG]

Hello!

I have been experiencing some trouble with the PStorage API. I have browsed every example and similar question I can find and none seem to match the continuing issues that I am having.

I have been very sure to register the pstorage event handler:

    static void sys_evt_dispatch(uint32_t sys_evt)
{
    if ((sys_evt == NRF_EVT_FLASH_OPERATION_SUCCESS) ||
            (sys_evt == NRF_EVT_FLASH_OPERATION_ERROR)) {
        pstorage_sys_event_handler(sys_evt);
    }
}

When I call on my functions to store or clear in pstorage, the pstorage events handler is never called, and as such no callback is sent and the queue element is not eliminated. As a temporary workaround, for the purposes of testing further, I made a small function to be called after my first store operation had actually written to memory.

 void cheap_trick(void){

	pstorage_sys_event_handler(NRF_EVT_FLASH_OPERATION_SUCCESS);
}

This allowed me, after having checked the write actually completed with a quick load operation, to simulate the event that the handler should be getting passed and remove it from the queue as it should be on completion, this was confirmed by running pstorage_access_status_get() showing 0 operations left in the queue.

However, the subsequent store operation is queued but fails to even write to the memory, even though in debugging I can see that it calls sd_flash_write() and returns NRF_SUCCESS there.

In addition I have called sd_flash_write()directly twice in a row to the first 4 then second 4 bytes of the pstorage block area, the first write succeeds and the second does not and using sd_evt_get() neither of these operation appears to be giving the NRF_EVT_FLASH_OPERATION_SUCCESS event on completion.

Is there somthing I could have missed in the setup of PStorage or could there be a problem in the Softdevice itself? I welcome all suggestions regarding solving this problem!

Thanks,

Chris

[Susheel Nuguru]

Pstorage Library is designed to work with Softdevice enabled because it uses sd_flash_xxx functions inside it.

sd_flash_xxx functions can work even if the softdevice is disabled, but they do not give the callbacks.

You wont get any events from softdevice (when it is disabled) because flash requests are completed synchronously as there do not have any competition for CPU time and AHB bus That means that when pstorage function call is returned your operation is already complete.

This is clearly given in the API documentation inside nrf_soc.h

/**@brief Flash Write
*
* Commands to write a buffer to flash
*
* If the SoftDevice is enabled:
*  This call initiates the flash access command, and its completion will be communicated to the
*  application with exactly one of the following events:
*      - @ref NRF_EVT_FLASH_OPERATION_SUCCESS - The command was successfully completed.
*      - @ref NRF_EVT_FLASH_OPERATION_ERROR   - The command could not be started.
*
* If the SoftDevice is not enabled no event will be generated, and this call will return @ref NRF_SUCCESS when the write has been completed
*

In short if softdevice is disabled, then your flash operation is completed immediately and it will never fail. If you still want to use pstorage with softdevice disabled, then you need use your so called "cheap_trick" function. I think the subsequent store operation should also pass if you call the cheap_trick() everytime you do a pstorage request. Could you debug more and see what blocked that subsequent store operation?

[ChrisG]

I have the Softdevice enabled, and have confirmed that it is definitely enabled with sd_softdevice_is_enabled(&sd_enabled) As far as the cheap trick method is concerned, it appears to work for a single element in queue but no subsequent queue elements that I add later function correctly.

I have debugged right through the subsequent store operation and ensured it reached the call to sd_flash_write, which did return NRF_SUCCESS however checking the memory location showed that it had not done anything.

[Susheel Nuguru]

but you said "BLE Stack is disabled " in your comment one hour before this.

[ChrisG]

Yes, the BLE stack is disabled, bluetooth / radio are not activated but the softdevice is enabled. They are two seperate entities that can be independently enabled if I have not misunderstood, or atleast that the softdevice can be enabled without the bluetooth stack.

I have double checked and the softdevice is definitely enabled.

Chris

[Susheel Nuguru]

Yes, sorry, we in Nordic use Stack in reference to softdevice, so i got little confused at the first look. You are right, they both are different entities, so the call back should work just fine if softdevice is enabled.

[ChrisG]

The system events do not appear to be being generated, and the pstorage handler is never being called. I have meanwhile been testing a little with sd_flash_write(); as follows:

sd_flash_write((uint32_t*)0x36C00, (uint32_t*)test_data_store, 1);
nrf_delay_ms(200);
sd_flash_write((uint32_t*)0x36C04, (uint32_t*)test_data_store, 1);
nrf_delay_ms(200);

This writes directly one word at a time to the area assigned for pstorage, the first operation succeeds and the memory location is correctly written to with the values provided. The second operation apparently succeeds, debugging through it shows no errors and it returns as NRF_SUCCESS however the memory location is still in an erased state, not written to.

There is some kind of fundamental error here that is not allowing more than one flash operation per reset of the chip. This goes for erase as well, following an erase, no store actually writes anything.