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
  • Stephan, 

    I have review reviewed the project you attached. This seems an IAR project and I cannot see the main project file apart from the .eww file And the issue does not appear to be caused by the wrong fstorage backend being selected. 

    The behavior is more consistent with the flash operation not completing in the Release build. When that happens, the firmware remains in its idle wait path and appears stuck in sd_app_evt_wait(). This can still look fine in Debug mode because the different timing, lower optimization, and active logging often mask this type of issue. Also, I see that the application writes to a fixed flash address (0x0007D000). That address must be confirmed against the final linker layout. If it overlaps a reserved flash region, the result can be unstable and may only become visible in Release mode. There are some other threads that mention that nrf_sdh_soc.c could be optimized away if you do not make sure it is used right.

    I cannot compile your project since it is IAR and I do not have a license for it. 

Reply
  • Stephan, 

    I have review reviewed the project you attached. This seems an IAR project and I cannot see the main project file apart from the .eww file And the issue does not appear to be caused by the wrong fstorage backend being selected. 

    The behavior is more consistent with the flash operation not completing in the Release build. When that happens, the firmware remains in its idle wait path and appears stuck in sd_app_evt_wait(). This can still look fine in Debug mode because the different timing, lower optimization, and active logging often mask this type of issue. Also, I see that the application writes to a fixed flash address (0x0007D000). That address must be confirmed against the final linker layout. If it overlaps a reserved flash region, the result can be unstable and may only become visible in Release mode. There are some other threads that mention that nrf_sdh_soc.c could be optimized away if you do not make sure it is used right.

    I cannot compile your project since it is IAR and I do not have a license for it. 

Children
Related