Unable to configure DSM_VIRTUAL_ADDR_MAX = 0 with Mesh SDK 4.0.0

[JonasJ]

Due to the rewrite of the DSM persistent storage layer the DSM_VIRTUAL_ADDR_MAX define can no longer be set to 0. This has changed since 3.2.0 where it could be 0.

During compilation the following static assert is hit.

nrf5-sdk-mesh/mesh/core/api/mesh_config_entry.h:105:5: note: in expansion of macro 'NRF_MESH_STATIC_ASSERT'
  105 |     NRF_MESH_STATIC_ASSERT((MAX_COUNT) > 0);                                                                        \
      |     ^~~~~~~~~~~~~~~~~~~~~~
nrf5-sdk-mesh/mesh/access/src/device_state_manager.c:1598:1: note: in expansion of macro 'MESH_CONFIG_ENTRY'
 1598 | MESH_CONFIG_ENTRY(dsm_virtual_addr,
      | ^~~~~~~~~~~~~~~~~

This happens since Mesh Config doesn't allow for 0 count.

The following patch restores the old possibility to disable virtual addresses if they aren't required.

diff --git a/mesh/access/src/device_state_manager.c b/mesh/access/src/device_state_manager.c
index 1447e9e..b87d708 100644
--- a/mesh/access/src/device_state_manager.c
+++ b/mesh/access/src/device_state_manager.c
@@ -1356,6 +1356,7 @@ static void dsm_nonvirtual_addr_getter(mesh_config_entry_id_t id, void * p_entry
     p_dst->addr = m_addresses[idx].address;
 }
 
+#if DSM_VIRTUAL_ADDR_MAX
 static uint32_t dsm_virtual_addr_setter(mesh_config_entry_id_t id, const void * p_entry)
 {
     if (!IS_IN_RANGE(id.record, MESH_OPT_DSM_VIRTUAL_ADDR_RECORD,
@@ -1388,6 +1389,7 @@ static void dsm_virtual_addr_getter(mesh_config_entry_id_t id, void * p_entry)
     dsm_entry_addr_virtual_t * p_dst = (dsm_entry_addr_virtual_t *)p_entry;
     memcpy(p_dst->uuid, m_virtual_addresses[idx].uuid, NRF_MESH_UUID_SIZE);
 }
+#endif /* DSM_VIRTUAL_ADDR_MAX */
 
 static uint32_t dsm_subnet_setter(mesh_config_entry_id_t id, const void * p_entry)
 {
@@ -1595,6 +1597,7 @@ MESH_CONFIG_ENTRY(dsm_nonvirtual_addr,
                   NULL,
                   NULL);
 
+#if DSM_VIRTUAL_ADDR_MAX
 MESH_CONFIG_ENTRY(dsm_virtual_addr,
                   MESH_OPT_DSM_VIRTUAL_ADDR_RECORD_EID,
                   DSM_VIRTUAL_ADDR_MAX,
@@ -1603,6 +1606,7 @@ MESH_CONFIG_ENTRY(dsm_virtual_addr,
                   dsm_virtual_addr_getter,
                   NULL,
                   NULL);
+#endif /* DSM_VIRTUAL_ADDR_MAX */
 
 MESH_CONFIG_ENTRY(dsm_subnet,
                   MESH_OPT_DSM_SUBNETS_RECORD_EID,

Thanks.

[tesc]

Hi,

Thank you for sharing the patch. I have registered it internally, for our developers to have a look.

Regards,
Terje

[tesc]

Hi,

The reason for a requirement of storage for at least one virtual address, is that virtual addresses is part of the Bluetooth mesh specification and you should be able to configure any model to use virtual addresses for publication or in the subscription list. What value to use depend on the node's models and the expected use, just as with DSM_NONVIRTUAL_ADDR_MAX, but even for a minimal node at least one virtual address configuration is plausible.

Regards,
Terje

[JonasJ]

Hi tesc,

I suspected that it boiled down to the Mesh Profile specification. Could you please point me to where in the standard it's mentioned that at least one Virtual and Non-Virtual address is required?

A proper MESH_STATIC_ASSERT with a comment about this might be in place to avoid hitting a limitation in the Mesh Config part.

Thanks.

[tesc]

Hi,

There is no direct mention of "how many virtual addresses to support" in the specification, but, from the Mesh Profile Specification, "4.3.2.17 Config Model Publication Virtual Address Set" and "4.3.2.20 Config Model Subscription Virtual Address Add" means virtual addresses must be supported. There are similar procedures for non-virtual addresses.

The need for configuring max values DSM_VIRTUAL_ADDR_MAX and DSM_NONVIRTUAL_ADDR_MAX arise purely from our stack implementation.

Worst case a model subscribes to a virtual address, and also fills a subscription list with virtual addresses. We consider supporting the use of at least one virtual address to be the absolute minimum for adhering to specification, although for any specific use case it would probably be higher.

These calculations quickly become complicated, as for instance models extending another model on the same element share subscription list with that model on that element. (Mesh Profile Specification section "4.2.3 Subscription List".) In practice it should be sufficient to set a value high enough for any conceivable intended use case for the node.

Regards,
Terje

[JonasJ]

Thanks for taking the time to explain.

I suspect that the standard only mandates the support for the messages "Config Model Publication Virtual Address Set" and a like. It's up to the device to respond with a proper status code in case it can't store the address due to "Insufficient Resources".

But yes, I can agree that it doesn't make much sense to have all the code for virtual addresses but not actually allocated resources to use it.

Regardless, there should be a proper MESH_STATIC_ASSERT() with a comment instead of depending on the mesh config code to assert on the count.

[tesc]

Hi,

Thank you for the feedback. We may choose to change this for a later release, so that it is more clear why this limitation is present and why it asserts.

Regards,
Terje