nRF5 Mesh (v1.0.1) flash memory overflow

[TomGates]

Hi,

I worked few years ago on a project with the configuration below :

• nRF Mesh SDK V1.0.1
• nRF52832
• I used the light switch example where the client and the provisioner were combined to made my project.

In my application there are 1 client/provisioner and 3 servers. The project was stopped for some reason and now I am working again on it.

Provisioning and communication worked fine. When I stop/start the products, the network works and the communication between servers and client continue.

But, after some days it appears that the client is in default. I have an uart used to debug and communicate with NRF52832 but there is no answer from the module. I restart it (on/off power supply) but it's still in default.

I read the programming application in client with nRFgo Studio to have the hex to compare with my application : it seems very different and I don't find the servers mesh information in flash (PERSISTENT_STORAGE).

I erase all flash in client and servers and I programmed them, the provisioning works and the communication works again.

To undestand what may happened, I read application in client with nRFgo Studio to compare hex files in different configuration (0, 1 or 2 servers, after a reset,...). I discovered than after a reset, the application write some data in flash memory, in the function net_state_recover_from_flash in net_state.c there is a function seqnum_block_allocate() which writes data in flash.

I made some tests and when I reset several time the client, some data are written in memory flash.

Part of memory (.hex)

  

Part of memory after some reset (.hex)

Is it possible to overflow the flash memory or application after a lot of write memory in flash ?

Is this issue known about the nRF Mesh SDK V1.0.1 ?

Is it possible to fix it without changing SDK version ?

Thank you,

Tom,

[Hung Bui]

Hi Gatesoupe, 

Could you give some more info about the application ? 
Do you have any special functionality, that you need to store data when in operation ? Does it turn off and on a lot when running ? 
Is there anyway to reproduce the issue without leaving it to run for a few days ? 
Can you reproduce the issue with our stock example (light switch) ? 

the SDK v1.0.1 is a very old SDK and it's hard for us to trace back if there is any issue back then. 

[TomGates]

Hi Hung,

Thank you for your answer.

The final application is a mesh network where each server make measurement every second. The client ask the value measured by each server every 5 seconds.

I don't really need to store data when in operation, just the network mesh information need to be stored in the client/provisionner after provisioning.

The client doesn't turn off when running but there is a reset of client every 30 minutes.

I will try to find a way to reproduce the issue faster with light switch example. 

[Hung Bui]

Hi  Gatesoupe, 

Do you have any log when the device stopped working ? Can you connect a debugger and let it run and check what at which line the code crashed ? 

I suspect that the sequence number was exceeded due to multiple reset (after each reset the sequence number is increased by one block). You can read more about how the sequence number block used here.

[TomGates]

Hi Hung,

Thank you for your answer.

I migrate my software from SDK Mesh V1.0.1 to SDK Mesh V5.0 and it's worked. But I have still an error when I made a lot of reset of my application. The error is : nrf mesh publish error 15 (forbidden)

I saw an other post with the same problem with SDK Mesh V4.1 : here.

If I understand well, after x number of resets, the device cannot send data on the mesh network.

Regards,

Tom,

[Hung Bui]

Hi Tom, 
Glad that it works now. 
You are correct. The implementation of the mesh stack doesn't support repeated reset of the device (the device supposed to be line powered and doesn't reset all the time). 

It's explained in the case you quoted. What happened is that we store a block number of the sequence number in flash. Every time the device boot up it will use the sequence number from the next block (this way we don't need to store the sequence number to flash on every single increment). So multiple resets will make the sequence number jump quickly to the end of the sequence and a IV index update needed to reset the sequence number. 

What you can do is to define a flag so that when you know that you are reset in a "controlled way", you retain the value of the sequence number in RAM and then reuse the number, instead of using the number of the next block. This way it will not jump a block. This only applied for softreset, not power reset /pin reset. 
If you are doing power reset you can think of reducing the size of the block if sequence number, so that it will not jump too fast to the maximum value of the sequence number. 

For such application that requires lots of reset or offline operation, I would suggest to implement it as  LPN node.