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

Loop in flash_manager_wait function() Mesh SDK 2.2.0, Light Switch Proxy Server Example

Hello, i am having problems with a loop in the function "flash_manager_wait()"; in the begining of the code.

main()-> initialize()-> mesh_init()-> mesh_stack_init(&init_params, &m_device_provisioned))-> dsm_flash_config_load()-> (void) dsm_flash_config_load()-> flash_manager_wait();

static inline void flash_manager_wait(void)
{
#if !defined(HOST)
//__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "HOLA 1..1..0..1\n");
while (!flash_manager_is_stable())
{
/* Temporary hack to make sure that bearer events are handled while waiting for
* the flash manager to finish.
* TODO: Find a solution for this that does not include busy-waiting. */
if (bearer_event_handler())
{
__WFE();
}
}
#endif
}

this happen after many reboots thath i do each 1 minute, and the only form to recover it, is erase all the flash, and re flashing soft-device and program.

i do the reboot whit the timer1 and the " function mesh_stack_device_reset()"

 void TIMER1_IRQHandler(void)
    {
        if (NRF_TIMER1->EVENTS_COMPARE[0] == 1 )
            {  
              __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- Count1 -----\n");
              NRF_TIMER1->EVENTS_COMPARE[0] =  0;
              if ( TIMER_REINICIO1 == 1)
              {
                 
                 nrf_delay_ms(100);
                  mesh_stack_device_reset();
                 
              }
            }
            
        if (NRF_TIMER1->EVENTS_COMPARE[1] == 1)
            {  
               __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "----- Count2 -----\n");
               NRF_TIMER1->EVENTS_COMPARE[1] = 0;
               
               if ( TIMER_REINICIO2 == 1)
              {
                
                 nrf_delay_ms(100);
                   mesh_stack_device_reset();
                 
              }
               
            }
    }

help please.

Parents
  • Hello,

    Is there a particular reason you have the nrf_delay_ms(100) in your timeout handler? It probably isn't that scary to use in mesh, but it may caused some unexpected behavior when you also use the "normal" BLE stack (proxy-example). At least if the softdevice is still running.

    I suspect that what might have happened is that the device is reset due to a softdevice assert, and not due to mesh_stack_device_reset(); at one point in time, and it was reset with an unstable flash, since the chip is halted for 100ms, which may crash with some softdevice event. When it returns, and is about to continue with the mesh_stack_device_reset, it may have been interrupted by a softdevice assert before having the time to do this.

    Can you try to remove the nrf_delay_ms() (also if you use them any other places).

    If that doesn't help, can you check which of the checks inside flash_manager_is_stable() that returns false?

    return (!packet_buffer_can_pop(&m_action_queue) && !flash_manager_defrag_is_running());

    Either packet_buffer_can_pop(&m_action_queue) returns true, or flash_manager_defrag_is_running() returns true.

    If you are still stuck after this, is it possible to send a project and some instructions on how I can replicate this?

    Best regards,

    Edvin

  • Hello, i want to know if you are working on this, or do you have some actualization ?

    Thanks.

  • Hello, Yes. I am looking into this. I still haven't found the reason for why it is stuck in the while loop. I will let you know as soon as I know.

    BR,

    Edvin

  • Hello,

    I have been talking to our Mesh Group, and this was an issue that they were aware of, and that they have actually fixed. Unfortunately, it is not a simple one liner, and the fix is spread out on several files. 

    I have tested the current dev branch of the Mesh SDK, and your application (main.c file) works as intended in that version. Unfortunately, I can't distribute this version now, but it will be included in the next release. 

    The issue is related to that the flash manager is waiting for a flash operation to be preformed, before the module that is going to perform this operation is initialized. 

    The issue should occur after about 500 resets with the currently available SDK for Mesh (2.2.0). Is this something you can work with until the official release is available? I can't give any guarantees for when that will happen, but it shouldn't be too long. Is this bug making it impossible for you to continue the development?

    Best regards,

    Edvin

  • Hi Edvin

    I'm having the same issue as reported by davidesteban13 above, ie hangs @ flash_manager_wait() using mesh stack 2.2.0, an nRF52840-DK,  S140_6.1.0 and an En_Ocean PTM215B switch.

    I have a production deadline to meet. Does Nordic have any other mitigation strategy other than asking customers to wait for the next as yet un-anounced SDK release?

    Millicent

  • Hello,

    The fix is implemented in the 3.0.0 release of the SDK. The flash manager has had a makeover. You can either port your application to this SDK version, or you can try to backport the flash manager. I recommend the first one.

    Best regards,

    Edvin

Reply Children
No Data
Related