using Pstorage while BLE scanning

RE: using Pstorage while BLE scanning

run_ar — Wed, 17 Feb 2016 13:01:00 GMT

As far as I can see you are not checking the error message returned by pstorage_update. Can you please check that this is NRF_SUCCESS, so that we know that the operation is actually queued.

RE: using Pstorage while BLE scanning

Jacob — Mon, 08 Feb 2016 15:01:19 GMT

Yes, you are right. I am using sd_ble_gap_scan_start.

Here is the code for the scan parameters:

#define SCAN_INTERVAL           0x00A0                          
#define SCAN_WINDOW             0x0050                         
#define SCAN_ACTIVE               1                              
#define SCAN_SELECTIVE          0                              
#define SCAN_TIMEOUT            0x01A4

static const ble_gap_scan_params_t m_scan_params = 
  {
    .active      = SCAN_ACTIVE,
    .selective   = SCAN_SELECTIVE,
    .p_whitelist = NULL,
    .interval    = SCAN_INTERVAL,
    .window      = SCAN_WINDOW,
    .timeout     = SCAN_TIMEOUT
  };

One thing that I tried is to call sd_ble_gap_scan_stop() before using pstorage. And, it did not work that I expected.

RE: using Pstorage while BLE scanning

run_ar — Mon, 08 Feb 2016 14:52:26 GMT

What is your scan parameters?

I assume you are using sd_ble_gap_scan_start? sd_ble_gap_connect has higher priority.

RE: using Pstorage while BLE scanning

Jacob — Mon, 08 Feb 2016 14:41:29 GMT

Thanks for sharing your idea, run_ar.

I tried to increase SD_CMD_MAX_TRIES and to give it a delay, but no luck. it keeps looping the while loop.

I am using a softdevice-s130_nrf51_2.0.0.7.alpha. Regarding your answer, is it possible to change pstorage priority higer?

RE: using Pstorage while BLE scanning

run_ar — Mon, 08 Feb 2016 06:11:57 GMT

Not sure which S130 version you are working with. But when you are using pstorage the Softdevice will calculate how much time flash operations need before granting it time in its scheduler. Update block means creating a swap block and erasing the main block before updating the block again. So I assume this is blocked as the softdevice is giving scanning priority. Consider updating the block after you are done scanning or increase SD_CMD_MAX_TRIES.