Getting a MESH ASSERT on 'subscription delete all'

[benjamin]

Hi,

as describe in the title, we are getting a mesh assert when trying to remove all suscibtions from a model.

it is kind of hard to reproduce because this command is not implemented in NrfMesh app, so we are implementing it in our App.

The assert appear when calling this command for the first time after a full erase of the dk board and the first provisionning.

regarding the SDK 4.1 for Nrf52840, the assert is caused by this:

device_state_manager.c : 2036 - 2048

uint32_t dsm_address_subscription_remove(dsm_handle_t address_handle)
{
    if (address_handle_valid(address_handle))
    {
        nrf_mesh_address_t addr;
        uint32_t status = dsm_address_get(address_handle, &addr);
        if (status == NRF_SUCCESS)
        {
            if (addr.type == NRF_MESH_ADDRESS_TYPE_GROUP)
            {
                if (m_addresses[address_handle].subscription_count == 0)
                {
                    return NRF_ERROR_NOT_FOUND;  // <-- this 

called from:

config_server.c : 496

        NRF_MESH_ASSERT(dsm_address_subscription_remove(subscribed_addresses[i]) == NRF_SUCCESS);

after restarting the node, this command works fine.

can you please take a look and tell me where is the probleme?

best regards

B

[Hung Bui]

Hi Benjamin, 

Could you let me know what you did before you called the function to erase all subscriptions ? Have you assigned a subscription address to any model ? 

It seems that the address has no subscription and then it end up in NRF_ERROR_NOT_FOUND. 

I'm curious about subscription_count and the subscribed_addresses[] array you have. 

[benjamin]

Hi, sorry for the late answer

here you have it

Best regards

[tesc]

Hi,

I suspect there may be a discrepancy between the states of the access layer and the device state manager. In this part of code, the number of subscriptions are checked using access layer functions, and then used for determining how many entries to delete from DSM. If access and DSM is out of sync at this point, then that could explain this error. If that is the case then I do not see any immediate way to fix this for an application, as it must be fixed in the mesh stack code itself.

I will report the issue to our developers, so they can look into it and hopefully reproduce and suggest a fix. Do you have a project running on an nRF DK or Dongle, where this issue can be easily reproduced?

Regards,
Terje

[benjamin]

Hi!

thank you for your explainations.

As I said, the easiest way is to erase compeletly the flash, program any mesh example, provision it and send the command.

Thank you

[benjamin]

HI

Any news about this ?

Thank you

Best regards

Ben

[Heidi]

Hi, 

Unfortunately, I have no updates yet. The mesh-team will take a look as soon as possible and try to fix it when they confirm it's a real bug. 

Due to the holidays in Norway, we are very low on staff in every department so delays are to be expected during the next few weeks.

Best regards,

Heidi

[tesc]

Hi,

The mesh team has not been able to reproduce.

It would be the best if our setup is as close to yours as possible, for reproducing.

• What example (or examples) did you test?
• Did you only provision, or did you do some configuration as well?
• What device or app did you use for provisioning (and for configuration, if applicable)?
• We assume that you send CONFIG_OPCODE_MODEL_SUBSCRIPTION_DELETE_ALL from the provisioner. With what parameters? (And if you do something else, please elaborate on how you trigger the delete.)

Regards,
Terje