pstorage is always pending and advertisement does not resume

[Gilson]

Hello Guys,

Everything was working fine with my nRF51822 device but all of the sudden the hardware started not to resume advertisements upon disconnecting from the host.

I debugged the issue down to the following function:

static void advertising_start(void)
{
    uint32_t err_code;
    uint32_t count;

    // Verify if there is any flash access pending, if yes delay starting advertising until 
    // it's complete.
    err_code = pstorage_access_status_get(&count);
    APP_ERROR_CHECK(err_code);
    
    if (count != 0)                <==== COUNT IS ALWAYS RETURNING NON-ZERO
    {
        m_memory_access_in_progress = true;
        return;
    }
    
    start_advertisement_timeout = false;
    err_code = sd_ble_gap_adv_start(&m_adv_params);
    APP_ERROR_CHECK(err_code);

}

So the code starts fine I see advertisements then I pair with the host as a mouse. I tell the host to disconnect and the nRF51822 should resume advertisements but something is causing Flash Access to be in a pending state because count is returning non-zero. why? what could it be?

pstorage_sys_event_handler(uint32_t sys_evt) is getting triggered but m_cmd_queue.flash_access is false. m_cmd_queue.count is equals 4.

Trying to understand this so I can fix the problem.

Thanks,

[Stefan Birnir Sverrisson]

Hi

Try to erase all bonding information from the device, see if that helps.

The device manager could be writing to flash memory before disconnecting. This is likely to be bonding information, which will be stored in flash before disconnecting. For the purpose of storing the bonding information, pstorage is used, which will queue up the flash operations, only sending one at a time to the softdevice, and sending the next flash operation when a callback is received from the softdevice that the previous flash operation has completed.

Since the count in the command queue is 4, there are still flash operations to be sent and completed. But the device will not start to advertise until this queue is empty. What happens is this:

• pstorage event is received indicating end of flash operation. The m_memory_access_in_progress flag is cleared and advertising is started by calling advertising_start()

    static void on_sys_evt(uint32_t sys_evt)
    {
    		switch(sys_evt)
    		{
    				case NRF_EVT_FLASH_OPERATION_SUCCESS:
    				case NRF_EVT_FLASH_OPERATION_ERROR:
    						if (m_memory_access_in_progress)
    						{
    								m_memory_access_in_progress = false;
    								advertising_start();
    						}
    						break;
    				default:
    						// No implementation needed.
    						break;
    		}
    }
  

in advertising_start, it is checked if there is any commands residing in the pstorage queue, if there are any, advertising is not started, the advertising_start function immediately returns and control is resumed to the main function loop where the chip will go to sleep with call to power_manage. The chip will wake up again on the next "pstorage operation completed" event and perform the same checks, and eventually start advertising when all pstorage operations are complete. If any pstorage opterations fail, they should time out and eventually generate a "pstorage operation complete" event, and advertising should start in any case.

Update 23.9.2015 The bug reported on this thread addresses the issue. The bug has been reported and a fix is expected in an upcoming SDK version. I suspect this bug is typically exposed when using pstorage and ADC/TEMP at at the same time, as they require 16MHz HFCLK crystal in order to operate, see nRF51822 PS v3.1, section 8.3. The ADC however does not actually need the crystal, it can use the RC, but the ADC accuracy may not be within specification.

A possible workaround would be to make the ADC use the 16MHz RC instead of the crystal. Another workaround would be to somehow make pstorage operations and HFCLK requests mutually exclusive.

[Gilson]

Actually, I found the root cause to the problem. Please let me know if you have an explanation for this. I'm doing ADC conversion and from the sample code I got the following:

sd_clock_hfclk_request();
while(! p_is_running) {  							//wait for the hfclk to be available
	sd_clock_hfclk_is_running((&p_is_running));
} 

So if the sd_clock_hfclk is running advertisement will not start because pstorage is pending. if I comment out the code above everything works fine and I see the advertisement resuming which means there are no pending flash operations. So it looks like the sd_clock is the reason.

It does not seem to affect the ADC conversion if we leave it off.

Do we need that clock for ADC accuracy?

[Stefan Birnir Sverrisson]

Hi. Yes, you need the 16MHz high frequency crystal for maximum accuracy for the ADC. If you do not explicitly enable the 16MHz crystal, then the 16MHz internal RC oscillator is used as the HFCLK clock source and it is more inaccurate.

[Edweirdo]

I have just run into the same error, could you please explain why the clock is causing this issue? I was wondering if it was tied to the fact that on our chips we have noticed issues with the XTALFREQ register, similar to what is described in anomaly 13 in PAN 2.1. However, we are using SOCs which follow PAN 3.0, so the whole thing is a bit odd.

In any case, is there a workaround? We would very much like to use the ADC, but not at the price of BLE advertising...

[Edweirdo]

Thanks for the update! I'll try adding the fix code to pstorage.c.