mesh sequence number reaches FFFFFF

[William.wei]

hi Support team,

Customer tested mesh SDK4.2, and now had one question:

their product is end node, and once button pressed, MCU is waked up and  send the message to server.which looks like ----reset and button press.

after a long time, find out the sequence number reaches 0xFFFFFF, and net_state_seqnum_alloc api will return NRF_ERROR_FORBIDDEN as below.

Even after reset, it still fails, how to solve this problem.

Regards,

William.

[Mttrinh]

Hi,

In the issue above they are seeing a sequence number exhaustion.

You can try one or more of the following:

Decrease NETWORK_SEQNUM_FLASH_BLOCK_SIZE (this will increase the use of flash, but low or no effect if it is frequent resets. This shouldn't be much bigger than a value that you expect to be used up as one approaches the next reset)

Decrease IV_UPDATE_TIMEOUT_PERIODIC_SAVE_MINUTES(This will increase the use of flash.It should be lower than expected uptime between resets).

Decrease NETWORK_MIN_IV_RECOVERY_INTERVAL_MINUTES (You won't be able to qualify as this will break the specification).

Turn on test mode so you can do IV Update whenever (You won't be able to qualify as this will break the specification).

Also, take a look at this thread for more info.

[William.wei]

Thanks Mttrinh，

Currently, customer product would go to system off mode to save power after sending the message, which takes about 300ms（button press, wake cpu, sending message, system off）, for suggestion 2,3 i think it is impossible to finish this mission.

for suggestion 1,i think it is useless.

for suggestions 4, any risks of this action? for me this would be the best solution for this product. i think this will also increase the flash usage, that would more than 100000 times flash erase, correct?

or i should change NETWORK_SEQNUM_FLASH_BLOCK_SIZE  to 20,

 and                       NETWORK_SEQNUM_FLASH_BLOCK_THRESHOLD to 10,

,anyway, product goes to system off mode, and will reset next time.

by the way, just want to confirm, that mesh parameter storage is using fds, right?

Regards,

William.

[Mttrinh]

William.wei said:

or i should change NETWORK_SEQNUM_FLASH_BLOCK_SIZE  to 3, since the message will be sent by three times as default, anyway, product goes to system off mode, and will reset next time.

NETWORK_SEQNUM_FLASH_BLOCK_SIZE defines the number of sequence numbers between every write to flash. In case of power failure, the device will resume transmissions with the first sequence number in the next block. A larger block size means that the device can do fewer resets between every IV Update, while a smaller will result in a reduced lifetime for the flash hardware. This depends on how often your device resets. They could for example try to decrease this value to 512.

The test mode is defined in the specification only for the purpose of executing the qualification tests, it is not defined meant to be used for usual use cases. 

[Mttrinh]

William.wei said:

Currently, customer product would go to system off mode to save power after sending the message, which takes about 300ms（button press, wake cpu, sending message, system off）, for suggestion 2,3 i think it is impossible to finish this mission.

From this it seems like the customer want to use the LPN feature instead. We do have an example here. Also, have a look at Low Power node feature and Integrating Low Power node feature.

William.wei said:

by the way, just want to confirm, that mesh parameter storage is using fds, right

No, Mesh uses their own Flash Manager.

[William.wei]

sorry Mttrinh,

i tested it and changed 

 change NETWORK_SEQNUM_FLASH_BLOCK_SIZE  to 20,

 and      NETWORK_SEQNUM_FLASH_BLOCK_THRESHOLD to 10,

each time device goes to system off, and wake up, sequence number will be updated. so it will not reach FFFFFF in her lifetime.

Regards,

William.

[Mttrinh]

Just remember that with smaller value of NETWORK_SEQNUM_FLASH_BLOCK_SIZE will result in a reduced lifetime for the flash. As mentioned this value shouldn't be much bigger than a value that you expect to be used up as one approaches the next reset.