NRF_MESH_ASSERT when sending more than 8126 messages.

[Jan]

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 

[Mttrinh]

Hi, 

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

[Jan]

Hi, 

It does not get to app_error_fault_handler (does not show up in the call stack). After the NRF_MESH_ASSERT (last picture) it goes straight to the default_mesh_assertion_handler and then sleeps forever. 

It seems that the programming is saving every message I send and then fails when it exceeds some value. How can I clear or expand this queue/memory block?

I have looked at some defines at nrf_mesh_config_core.h but could not find anything yet.

Hope you can help me.

Jan

[Mttrinh]

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?

[Jan]

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.

[Jan]

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

[Mttrinh]

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);
            }
        }
    }
}