Problem with fstorage and ble active in Release mode

I'm using nRF52832 SoC with nRF5_SDK17.1.0 and SoftDevice v7.3.0. I'm using following code to write data into flash.

 err_code = nrf_fstorage_write(&g_fs, write_addr, buffer32, 128, NULL);

  wait_while_fs_busy(&g_fs);

/* Wait helper: sleep while fstorage is busy (write/erase are async). */
static void wait_while_fs_busy(nrf_fstorage_t const * p_fs)
{
    uint32_t waited_ms = 0;

    while (nrf_fstorage_is_busy(p_fs))
    {

      if ((p_fs->p_api == &nrf_fstorage_sd) && nrf_sdh_is_enabled())
      {
           __enable_irq();
           __set_BASEPRI(0);
           (void)sd_app_evt_wait();
      }
      else
      {
            __WFE();
      }

      (void)NRF_LOG_PROCESS();
      waited_ms++;
      if (waited_ms > 5000)
      {
         NRF_LOG_ERROR("fstorage wait timeout");
         break;
      }
      NRF_LOG_PROCESS();
   }
}

It works fine when compiled in debug mode.

Whenever it's compiled in release mode and fstorage is used while ble is connected, the code enters 2 to 3 times sd_app_evt_wait(); an then hangs in this function.

Whenever it's compiled in release mode and fstorage is used after ble is disconnected, the code enters sd_app_evt_wait(); and hangs in this function immediately.

--> I guess no event is generated any more or masked.

Why this is happening?

Parents
  • Hi Stephan

    Sorry I didn't get back to you yesterday.

    I have done some more testing now, and tried writing and reading the device name characteristic from the nRF Connect for Mobile app, and that seems to work. The Device name (characteristic data) does not change before the device has been reset though, which is expected, since the Bluetooth controller (SoftDevice) needs to reinitialize with the new name for it to take effect, so that might be what you're seeing here.

    It still seems to behave the same in debug mode and release mode to me. Where it advertises for a short amount of time upon starting where I can connect to it and stay connected for as long as I want. The service and characteristic works as expected from what I can see, where you need to uninit and reinitialize the application for the device name changes to take effect. I'm also able to reconnect after connecting -> changing the device name -> resetting the device -> reconnect

    You say you do "Build and debug" and see the name is not changed. This is expected, as that would mean you flash the application with the original device name again when flashing the device in debug mode again. So it's also expected that the registers wouldn't change when you flash the device before going into debug mode.

    Best regards,

    Simon

Reply
  • Hi Stephan

    Sorry I didn't get back to you yesterday.

    I have done some more testing now, and tried writing and reading the device name characteristic from the nRF Connect for Mobile app, and that seems to work. The Device name (characteristic data) does not change before the device has been reset though, which is expected, since the Bluetooth controller (SoftDevice) needs to reinitialize with the new name for it to take effect, so that might be what you're seeing here.

    It still seems to behave the same in debug mode and release mode to me. Where it advertises for a short amount of time upon starting where I can connect to it and stay connected for as long as I want. The service and characteristic works as expected from what I can see, where you need to uninit and reinitialize the application for the device name changes to take effect. I'm also able to reconnect after connecting -> changing the device name -> resetting the device -> reconnect

    You say you do "Build and debug" and see the name is not changed. This is expected, as that would mean you flash the application with the original device name again when flashing the device in debug mode again. So it's also expected that the registers wouldn't change when you flash the device before going into debug mode.

    Best regards,

    Simon

Children
  • Hi Simon - thanks for your effort you made. 

    Have you explicitly checked and can you confirm that when programmed with 'Build and Run' the new name (actually the whole 128 byte package of the struct 'dev_block.info') is being written to the flash on a following start address in the same flash page? See the red marked 128 byte block under g) in my previous description from March 23rd.
    Siede note: in a page is space for 32 blocks of 128 byte; we use only 31 blocks.

    The problem is not that the new name is not immediately adopted for BT advertising without a restart. Our issue is that the new name or data is not written into the flash memory in this mode.

    Best
    Stephan

Related