BLE interfering with pstorage_update?

[julian24]

Hello everyone,

I have a problem using pstorage_update. Normally it does as it should, but once i call ble_stack_init(); on my code, pstorage_update doesn't work anymore, it just doesn't take action, does anybody know why? I even reinitialized the softdevice before using pstorage_update but it was no use. I'm using the ble stack init provided in the sdk example codes.

/**@brief Function for the S110 SoftDevice initialization.
 *
 * @details This function initializes the S110 SoftDevice and the BLE event interrupt.
 */
static void ble_stack_init(void)
{
    uint32_t err_code;
    
    // Initialize SoftDevice.
    SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_20_PPM, NULL);

    // Enable BLE stack.
    ble_enable_params_t ble_enable_params;
    memset(&ble_enable_params, 0, sizeof(ble_enable_params));
#if (defined(S130) || defined(S132))
    ble_enable_params.gatts_enable_params.attr_tab_size   = BLE_GATTS_ATTR_TAB_SIZE_DEFAULT;
#endif
    ble_enable_params.gatts_enable_params.service_changed = IS_SRVC_CHANGED_CHARACT_PRESENT;
    err_code = sd_ble_enable(&ble_enable_params);
    APP_ERROR_CHECK(err_code);
    
    // Subscribe for BLE events.
    err_code = softdevice_ble_evt_handler_set(ble_evt_dispatch);
    APP_ERROR_CHECK(err_code);
}

[Einar Thorsrud]

Hi,

Which SDK version are you using? When using pstorage that in turn use SoftDevice APIs for writing to flash. The SoftDevice will schedule flash write operations in between BLE events as the CPU and radio cannot be used while writing to flash. If the connection parameters are tight for instance, the SoftDevice wills truggle with schedulign the write operation. It could also be a configuration issue of some sort (this is quite old stuff that I must admitt I don't recall that well). You may want to refer to this old unofficial sample showing usage of pstorage and SoftDevice.

[julian24]

apparently the problem is on this line:


// Subscribe for BLE events.
err_code = softdevice_ble_evt_handler_set(ble_evt_dispatch);


i made a custom function to make the pointer of the ble handler point to NULL after stopping advertising, and it doesn't seem to bother anymore.

i still dont know why it happens this way, so id really like information on the topic.

if i leave the pointer pointing to my ble dispatcher, pstorage_update never ends the memory saving

[Einar Thorsrud]

That means you are effectively not processing any SoftDevice events? I expect that will give you other problems down the line (unless your device is only advertising, in that case, you may not need to handle any events).

If the the problem is the BLE event handler, then I would look at all the functions you call from ble_evt_dispatch and digg down to see if any of those spend a long ammount of time (or even worse never returns), effectively blocking in an interrupt. This may not be the problem, but it is a gut feeling.

Other than that I cannot say more without knowing more (perhaps you have learned more from debugging?). And the SDK version is also important as there have been many changes in the SDK over the years.

[julian24]

I'm using SDK v10. I'm theoretically still processing SoftDevice events, just not the BLE ones.

My problem hasn't been solved, I just noticed that everything seems to work fine i "reset" the ble handler pointer back to NULL. There's no way to do this but to use a custom function which is really impractical.

I just need help from someone from Nordic who may explain why this happens or how can i solve it in a practical way that doesn't involve changing an SDK lib file.

What I've found so far is that setting the BLE handler makes so that pstorage never completes the update operation.

[Einar Thorsrud]

Hi,

The workaround you have found seems like a dirty hack so I would not pursue that approach (regardless of if involves changing SDK files or files in your application). Instead, I would focus on finding the root cause of this issue.

As you are usign a very old SDK I assume this is an old product and you made recent changes that made this issue appear? If so, I would start by looking at those reasent changes. Does the issue disappear if you revert the changes? If so, what was the changes?

[julian24]

Hi.

Yes, I am aware it's a dirty hack and that's precisely why I'm asking for help. The changes consisted in making an extra custom function inside softdevice_handler.c, which sets m_ble_evt_handler to NULL as I already explained (I call this function in my main code since it's my only way to reset the m_ble_evt_handler pointer). if i don't use this function to set the pointer to NULL, pstorage never completes the update. I precisely need help to understand why this is happening as this is all I'm doing with the code.

In other words, you could say that my dirty hack reverts the line err_code = softdevice_ble_evt_handler_set(&ble_evt_dispatch).

[Einar Thorsrud]

Hi,

Good, then we are on the same page. The next step is to try to understand the root cause of this issue, for which more information and debuggis is needed. Can you by sharing which chagnes you did that introduced this issue?