Hi, I am noticing a potential underlying issue with Nordic's LC server example containing the scene and scene setup server.
Environment:
1. Segger Embedded Studio V5.66
2. nrf5 SDK for Mesh V5.0
3. nrf5 SDK V17.02
4. NRF52840 DK
Reproduce:
1. Flash an NRF52840 DK with the LC server example
2. Provision the Device
3. Store 4 scenes on the device
4. Send consecutive scene recall messages toggling between two different scenes from a scene client
The issue appears on a Scene Recall operation on the server side. When a scene is recalled and the recalled scene number is different from the current scene number, something hogs the processor completely.
This is what I've found:
1. The size of the lc_flash_storage_state_t structure in light_lc_mc.c is 1124 (1122 with tight packing) bytes (Assuming that SCENE_REGISTER_ARRAY_SIZE is 16):
2. Toggle a GPIO to time the flash_manager_defrag() function in flash_manager_defrag.c :
3. Below is the timing diagram for the above every time a different scene number is recalled:
The GPIO is set high when flash_manager_defrag() enters and low when flash_manager_defrag() returns. There are roughly 23 calls to the function. This carries on for ~4.7 seconds and I can see everything on the device being locked out completely. If you keep spamming the device with scene recalls eventually flash area 0xFA000 corrupts and asserts on startup. That area is used for mesh configuration data.
Sometimes I am also getting the disassembly as shown below.:
Flash area 0xa60 is part of the SoftDevice, I understand that you cannot see that function call because only the binary files for the SoftDevice is supplied. There seems to be a correlation between the mentioned issue and the above, but I am not exactly sure what the cause is. It might be a watchdog reset.
4. Workaround:
Reduce the SCENE_REGISTER_ARRAY_SIZE to 14. The size of lc_flash_storage_state_t is then 996 bytes.
I am aware that a device should be able to store exactly 16 scenes to be mesh compliant. The workaround seems to work, as long as the size of lc_flash_storage_state_t is below 1024 bytes.
Conclusion:
With SCENE_REGISTER_ARRAY_SIZE = 16, it seems like every time a different scene is recalled on the server side a de-fragmentation process starts and locks out everything else. Even if the defragging process was handled differently, it would still not be ideal to start that process on every scene recall change.
What would be the appropriate solution for this? Fundamentally I would think you have to reduce the size of the lc_flash_storage_state_t structure in light_lc_mc.c module. So perhaps change the design around storing the scene data, and handle it per scene and not in one structure containing all of the scene data?
Regards
Chris
