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

NRF_MESH_ASSERT when sending more than 8126 messages.

Hi all,

I'm currently implementing a Bluetooth Mesh system for testing various network characteristics. 

I am running some tests were a Nordic Thingy:52 is sending a lot of messages. Unfortunately, after sending 8126 messages, my sending node crashes with the following:   

<t: 7526098>, nrf_mesh_node_config.c, 118, MESH ASSERT at 0x0002EF38

This is always the case, even with different delays between sending (I've tested sending every 25, 50 and 100ms). 

Some additional information:

-I am using Mesh SDK version 1.0.1.

-This is the call stack;

- Memory usage

- The actual function that causes the assert (which was always there)

I have absolutely no clue what is going wrong and I hope someone can help me. I am pretty new to Mesh and the SDK since i'm a student. 

If any additional info is helpful please let me know.

Jan 

Parents
  • Hi, 

    Can you try to debug the code? Set a breakpoint at app_error_fault_handler and see what error code you get.

  • Instead of using a delay between each message, you can try waiting for the NRF_MESH_EVT_TX_COMPLETE event before sending your next message. This will at least ensure that the buffer won't fill up. Can you see if this solves this or makes any difference?

  • Hi,

    I just tested it, the NRF_MESH_EVT_TX_COMPLETE happens before sending the new message. Is also happens just as often as I call my send function. It even happens for the very last message that is sent before crashing. So that is not the problem.

    Please let me know what else could be the problem. 

    If you look at my call stack, you can see there are some flash writing actions. I think it has to do something with this but I don't know what.

  • Hi,

    It might be worth adding that my program is adapted from this example. Maybe one of the developers of this example can easily point me to the problem. 

    Jan

  • Hi,

    This seems to be a known issue with Mesh SDK v1.0.x. You should be able to solve this by switching two lines of code inside seqnum_block_allocate in net_state.c:

    static void seqnum_block_allocate(void)
    {
        if (!m_seqnum_allocation_in_progress)
        {
            uint32_t next_block = m_net_state.seqnum_max_available + NETWORK_SEQNUM_FLASH_BLOCK_SIZE;
            if (next_block <= NETWORK_SEQNUM_MAX + 1)
            {
                fm_entry_t * p_new_entry = flash_manager_entry_alloc(&m_flash_manager, FLASH_HANDLE_SEQNUM, sizeof(net_flash_data_sequence_number_t));
                if (p_new_entry == NULL)
                {
                    /* try again later */
                    static fm_mem_listener_t mem_listener = {.callback = flash_mem_available,
                                                            .p_args = seqnum_block_allocate};
                    flash_manager_mem_listener_register(&mem_listener);
                }
                else
                {
                    p_new_entry->data[0] = next_block;
                --  flash_manager_entry_commit(p_new_entry);
                    m_seqnum_allocation_in_progress = true;
                ++  flash_manager_entry_commit(p_new_entry);
                }
            }
        }
    }

Reply
  • Hi,

    This seems to be a known issue with Mesh SDK v1.0.x. You should be able to solve this by switching two lines of code inside seqnum_block_allocate in net_state.c:

    static void seqnum_block_allocate(void)
    {
        if (!m_seqnum_allocation_in_progress)
        {
            uint32_t next_block = m_net_state.seqnum_max_available + NETWORK_SEQNUM_FLASH_BLOCK_SIZE;
            if (next_block <= NETWORK_SEQNUM_MAX + 1)
            {
                fm_entry_t * p_new_entry = flash_manager_entry_alloc(&m_flash_manager, FLASH_HANDLE_SEQNUM, sizeof(net_flash_data_sequence_number_t));
                if (p_new_entry == NULL)
                {
                    /* try again later */
                    static fm_mem_listener_t mem_listener = {.callback = flash_mem_available,
                                                            .p_args = seqnum_block_allocate};
                    flash_manager_mem_listener_register(&mem_listener);
                }
                else
                {
                    p_new_entry->data[0] = next_block;
                --  flash_manager_entry_commit(p_new_entry);
                    m_seqnum_allocation_in_progress = true;
                ++  flash_manager_entry_commit(p_new_entry);
                }
            }
        }
    }

Children
Related