Adding more channels to dimming_server mesh example

[jhuebner]

Hi,

I have a project where we want to setup 3 PWM channels for dimming LED strings in a mesh configuration. So the mesh dimming server is a perfect starting point. I did run into a few issues that I "fixed" but I don't really now what other implications that might have.

-#define ACCESS_MODEL_COUNT (3)
+#define ACCESS_MODEL_COUNT (ACCESS_ELEMENT_COUNT + 2)

-#define ACCESS_ELEMENT_COUNT (1)
+#define ACCESS_ELEMENT_COUNT (3)

-#define DSM_APP_MAX                                     (8)
+#define DSM_APP_MAX                                     (4)

-#define DSM_VIRTUAL_ADDR_MAX                            (2)
+#define DSM_VIRTUAL_ADDR_MAX                            (10)

-#define DSM_NONVIRTUAL_ADDR_MAX                         (3)
+#define DSM_NONVIRTUAL_ADDR_MAX                         (10)

I might have overdone some but at least it worked.

Adding the extra servers and PWM channels to the main.c was pretty straight forward, not gonna quote it here. Now comes the hairy stuff: whenever the Mesh App arrived at "sending provisioning data..." the firmware conked out with error 5 (something not found). It turns out the culprit was the ACCESS_INTERNAL_STATE_ALLOCATED in access.c . Whenever loading config from flash failed, it will be reset to 0 resulting in the error 5. So I modified mesh_stack.c:

-    access_clear();
+    //access_clear();

That solves it but with what side effect?

Next I figured even though my node now worked that the mesh configuration doesn't get stored (or better, not reloaded at boot) Thats because the metadata still contained the old values of ACCESS_MODEL_COUNT etc. So I did modification to device_state_manager.c and access.c

     if (!!m_status.is_load_failed)
     {
+        metadata_store();
         return NRF_ERROR_INVALID_DATA;
     }

So if you can't load it, overwrite with something valid. That solved the problem. Again: with what side effect?

[jhuebner]

Hi, yes I want to know the root cause too, thus the ticket.

The function call config_server_bind(devkey_handle); in mesh_stack.c:192 returns 5

This boils down to access.c:242

return (handle < ACCESS_MODEL_COUNT && ACCESS_INTERNAL_STATE_IS_ALLOCATED(m_model_pool[handle].internal_state));

So it is marked not allocated because the function access_clear() that is called upon a failed flash load marks it so.

[Edvin]

Ok, I see.

This line from your snippet: 

Try to hardcode your 

#define ACCESS_MODEL_COUNT (ACCESS_ELEMENT_COUNT + 2)

to not be dependent on ACCESS_ELEMENT_COUNT. If you want that, at least put it beneath the definition of ACCESS_ELEMENT_COUNT, in case it is set too low. 

If you are having flash issues, then it is likely because something doesn't match the number of models and elements that you are trying to use. 

Why did you decide to remove access_clear()? I am sorry if this is obvious, but I am trying to catch up with what you were thinking. Did it fail somewhere else before you removed this?

Just a shot in the dark:

Did you ever completely erase the chip after adding the two PWMs to your mesh model? So that it is not trying to use some old configurations stored in flash with your new configurations?

Best regards,

Edvin

[jhuebner]

Yes, can you elaborate on ACCESS_MODEL_COUNT? The documentation is not too clear on that. Is it even related to ACCESS_ELEMENT_COUNT? I thought it was HealthModel+ConfigurationModel+3*LevelModel?

No I think I never did a complete chip erase in order to not have to reflash theSoftDevice every time. But thats probably the culprit. BUT: what if I do a field firmware update (DFU) that changes the number of elements or models? Wouldn't that cause the same problem?

I removed access_clear() because it reset the IS_ALLOCATED flag and that caused the error 5 further down the line.

[Edvin]

jhuebner said:

No I think I never did a complete chip erase in order to not have to reflash theSoftDevice every time. But thats probably the culprit. BUT: what if I do a field firmware update (DFU) that changes the number of elements or models? Wouldn't that cause the same problem?

 That is a good point. I don't think it really matters to erase it completely. It is mostly the network data that is stored in flash (network keys). 

I don't remember exactly what you need to set as access element and access model count. My concern in the previous reply was that from your snippet you say that ACCESS_MODEL_COUNT is dependent on ACCESS_ELEMENT_COUNT, but ACCESS_ELEMENT_COUNT is defined after ACCESS_MODEL_COUNT. If you are unlucky, that leads to other values than you would think you use. 

If you want to add to elements in one of your models, try to increase only ACCESS_ELEMENT_COUNT by 2, but without the dependencies. Just set it to 5.