RE: Mesh assertion during sequence number block allocate

pquevedo — Tue, 16 Jun 2020 14:37:58 GMT

Any update on this issue? I am also running into this on v4.1.0 when add subscriptions to the DSM from the application_scheduler.

Here is my stack trace if that helps.

#3  0x0001ce04 in mesh_assertion_handler (pc=181202) at /Users/paulquevedo/dev/thor/nordic/mesh/ledProvTest/src/error_handlers.c:75
#4  0x0002c3d8 in backend_evt_handler (p_evt=0x2003f560) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config.c:270
#5  0x0002cbda in write_complete_cb (p_manager=0x20006d10 <m_dsm_file_backend_data+8>, p_entry=0xeb084, result=FM_RESULT_SUCCESS)
    at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config_flashman_glue.c:125
#6  0x000290a6 in end_action (p_action=0x200058a0 <m_action_queue_buffer+4>, result=FM_RESULT_SUCCESS, p_entry=0xeb084) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/flash_manager.c:486
#7  0x000296be in process_action_queue () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/flash_manager.c:788
#8  0x00029720 in flash_op_ended_callback (user=MESH_FLASH_USER_MESH, p_op=0x20005524 <m_users+248>, token=26) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/flash_manager.c:807
#9  0x00023894 in send_end_events () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_flash.c:159
#10 0x000267ee in bearer_event_handler () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/bearer_event.c:380
#11 0x000263f8 in QDEC_IRQHandler () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/bearer_event.c:145
#12 <signal handler called>
#13 0x00026694 in bearer_event_flag_set (flag=3) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/bearer_event.c:304
#14 0x000289fa in schedule_processing () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/flash_manager.c:126
#15 0x00029bcc in flash_manager_entry_commit (p_entry=0x200058ac <m_action_queue_buffer+16>) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/flash_manager.c:1169
#16 0x0002cd8a in mesh_config_backend_record_write (p_file=0x20006d08 <m_dsm_file_backend_data>, p_data=0x2003f6b8 "\001\300\003 +\255\002", length=2)
    at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config_flashman_glue.c:257
#17 0x0002ca38 in mesh_config_backend_store (id=..., p_entry=0x2003f6b8 "\001\300\003 +\255\002", entry_len=2) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config_backend.c:139
#18 0x0002c16e in dirty_entries_process () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config.c:163
#19 0x0002c264 in entry_store (p_params=0x551b8 <m_dsm_nonvirtual_addr_params>, id=..., p_entry=0x2003f760) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config.c:200
#20 0x0002c644 in mesh_config_entry_set (id=..., p_entry=0x2003f760) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/core/src/mesh_config.c:401
#21 0x00035972 in dsm_entry_store (record_id=4096, handle=2, p_property=0x20006c88 <m_addr_nonvirtual_allocated>) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/access/src/device_state_manager.c:1674
#22 0x00034e04 in add_address (raw_address=49153, p_address_handle=0x2003f7be, role=DSM_ADDRESS_ROLE_SUBSCRIBE) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/access/src/device_state_manager.c:1033
#23 0x00035f44 in dsm_address_subscription_add (raw_address=49153, p_address_handle=0x2003f7be) at /Users/paulquevedo/dev/thor/Dependencies/nRF5_Mesh_SDK/4.1.0/src/mesh/access/src/device_state_manager.c:1948
#24 0x0004a7be in measurement_subscribe (argptr=0x20003660 <APP_SCHED_BUF.12703+360>, argsize=4) at /Users/paulquevedo/dev/thor/nordic/mesh/common/src/models/daylight.c:206
#25 0x00043728 in app_sched_execute () at /Users/paulquevedo/dev/thor/Dependencies/nRF5_SDK/16.0.0/src/components/libraries/scheduler/app_scheduler.c:280
#26 0x0001ce58 in applicationStep () at /Users/paulquevedo/dev/thor/test/include/application.h:28
#27 0x0001d294 in main () at /Users/paulquevedo/dev/thor/test/src/main.c:239

RE: Mesh assertion during sequence number block allocate

Inti3456 — Thu, 07 May 2020 01:49:27 GMT

It appears that during the call to seqnum_block_allocate, we make a call to dirty_entries_process() which calls the following line:

status = mesh_config_backend_store(id, buf, p_params->entry_size);

static void dirty_entries_process(void)
{
#if PERSISTENT_STORAGE
    FOR_EACH_ENTRY(p_params)
    {
        const mesh_config_file_params_t * p_file = file_params_find(p_params->p_id->file);
        NRF_MESH_ASSERT(p_file);
        if (p_file->strategy == MESH_CONFIG_STRATEGY_CONTINUOUS ||
           (p_file->strategy == MESH_CONFIG_STRATEGY_ON_POWER_DOWN && m_emergency_action))
        {
            for (uint32_t j = 0; j < p_params->max_count; ++j)
            {
                if ((p_params->p_state[j] & MESH_CONFIG_ENTRY_FLAG_DIRTY) &&
                   !(p_params->p_state[j] & MESH_CONFIG_ENTRY_FLAG_BUSY))
                {
                    mesh_config_entry_id_t id = *p_params->p_id;
                    id.record += j;
                    uint32_t status;

                    if (p_params->p_state[j] & MESH_CONFIG_ENTRY_FLAG_ACTIVE)
                    {
                        /* The backend has to make a copy, as the buffer is on stack! */
                        uint8_t buf[MESH_CONFIG_ENTRY_MAX_SIZE] __attribute__((aligned(WORD_SIZE)));

                        p_params->callbacks.getter(id, buf);

                        status = mesh_config_backend_store(id, buf, p_params->entry_size);
                    }
                    else
                    {
                        status = mesh_config_backend_erase(id);
                    }

                    switch (status)
                    {
                        case NRF_SUCCESS:
                            p_params->p_state[j] &= (mesh_config_entry_flags_t)~MESH_CONFIG_ENTRY_FLAG_DIRTY;
                            p_params->p_state[j] |= MESH_CONFIG_ENTRY_FLAG_BUSY;
                            break;
                        case NRF_ERROR_NOT_FOUND:
                            /* This can only happen with mesh_config_backend_erase() on not written yet entry. */
                            p_params->p_state[j] &= (mesh_config_entry_flags_t)~MESH_CONFIG_ENTRY_FLAG_DIRTY;
                            break;
                        default:
                            /* Back off if the backend call fails, to allow it to free up some resources */
                            return;
                    }
                }
            }
        }
    }
#endif
}

This line appears to trigger the backend_evt_handler before the status can be checked in dirty_entries_process() which on NRF_SUCCESS sets the MESH_CONFIG_ENTRY_FLAG_BUSY flag. This is the flag that the NRF_MESH_ASSERT is checking and doesn't seem to be set the first time backend_evt_handler is called.