This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Migrating to SDK 10 from 8 breaks application pstorage code

We have based our code off of ble_app_proximity. Upon first connecting to the advertising NRF51822AB device with softdevice 110 v8.0.0, we write to pstorage.

static void on_ble_evt(ble_evt_t * p_ble_evt)
{

    uint32_t        err_code = NRF_SUCCESS;
    static uint16_t m_conn_handle = BLE_CONN_HANDLE_INVALID;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
        {
                value[0] = 1;
                err_code = pstorage_update(&flash_block_handler, value, 4, 0);

Unfortunately, after disconnecting, the device attempts to begin advertising again and fails to go very far into the advertising_start() code.

static void advertising_start(void)
{

uint32_t  err_code;
ble_gap_adv_params_t adv_params;
ble_gap_whitelist_t  whitelist;
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)
{
    m_memory_access_in_progress = true;
    return;
}

Count starts at 0, but upon connecting and then disconnecting to trigger re-advertising, the count now is set to 1 and bluetooth advertisement packets fail to appear.

When we used sdk 8 the pstorage count was always 0. Now that we are using SDK 10, pstorage_access_status_get sets count to 1, and advertising does not restart.

In our system event handler, we watch for the flash to finish, but the flash never triggers an event:

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;

While debugging, I found that the pstorage_update function does a 'page swap erase' first, and upon entering this function

pstorage.c

flash_api_err_code_process(sd_flash_page_erase(page_number));

sd_flash_page_erase appears to have a return value of 0x0000000F. The code was compiled in optimization level 1, so I'm not sure if the return value of F is an artifact of the optimization.

Thank you in advance for reading this and for your assistance.

Parents
  • Discovered the bug. While updating, we needed to change the referenced header file pstorage_platform.h.

    Previously a definition was named PSTORAGE_MAX_APPLICATIONS and that has now been changed to PSTORAGE_NUM_OF_PAGES. We needed to update the definition of PSTORAGE_NUM_OF_PAGES to match our old PSTORAGE_MAX_APPLICATIONS, which was set to 4.

Reply
  • Discovered the bug. While updating, we needed to change the referenced header file pstorage_platform.h.

    Previously a definition was named PSTORAGE_MAX_APPLICATIONS and that has now been changed to PSTORAGE_NUM_OF_PAGES. We needed to update the definition of PSTORAGE_NUM_OF_PAGES to match our old PSTORAGE_MAX_APPLICATIONS, which was set to 4.

Children
No Data
Related