NRF Mesh and Flash organisation and SD

[Simsim]

Hi There

while extending the actual Sofware with more flash entries i discovered that the capability of provisioing devices decreases, and end up in a hardfault.

Is there a description how to manage this?

Base: NRF MESH SDK 5.0, Dimming Server with provisioner functionality, without the User Flash Page 0x0019 the Node count stopps at 14, with it its at 6. It happend when provisioning an configuring is complete and key should be added to the Softdevice list.

Memory Settings Segger Studio:

FLASH_PH_START=0x0

FLASH_PH_SIZE=0x1ef8000

FLASH_START=0x27000

RAM_PH_START=0x20000000

RAM_PH_SIZE=0x3f000

RAM_START=0x20002e00

Memory Map read out with Programmer:

User Data ends at 0x000EE000

Regards

Simon

[Hung Bui]

Hi Simon, 
This sounds strange. Could you please clarify: 

- What you meant by "User Flash Page"  ? Please be specific. 

- Did you do any modification to the provisioner on how it store provisioning & configuration data  ? Could you check how much space the provisioning and configuration data for a node occupy ? 

- Could you try to reproduce the issue with the unmodified provisioner example ? 

- When you say " Node count stopps at 14" what exactly happens ? 

Please be noted that the embedded provisioner is not a recommended solution for larger network. It was made as a proof of concept to show how provisioning can be done. The challenge is that the nRF52 can't really handle a large flash database with hundreds / thousands of node. You will have a challenge back up and restore the database. 

A solution where the database is stored on PC/Mobilephone/cloud is a better solution. 

nRF5 SDK for Mesh has been discontinued 5 years ago, for new development we suggest nRF Connect SDK. 

[Simsim]

Hi Hung Bui

I am aware of the discontinuity of the nrf Mesh SDK

- When you say " Node count stopps at 14" what exactly happens

..Provisioning node 14

..Provisioninh done,

..Configure Node

..Configure Node 14 Done, succesfully

..... freeze, no assert, hardfault just stopped the processor suddenly disconnect when connected over GATT

LOG:

<t:     251360>, node_setup.c,  663, Adding subscription to address 0xC005 for Generic Level client on element address 0x032B
<t:     262327>, transport.c, 1045, Message decrypted
<t:     262341>, main.c, 1022, Config client event
<t:     262343>, node_setup.c,  292, opcode status field: 0 
<t:     262347>, main.c,  966, Configuration of device 14 successful
<t:     262350>, main.c, 1878, Provisioner_Store ID:   10 Rec:   10 ERROR: 0
<t:     262354>, main.c, 2338, -->MESH message add to Buffer Write: F Read: F 
<t:     263053>, main.c, 2372, Filllevel mesh sendbuffer is---------------------------------------------: 3 
<t:     263057>, main.c, 2156, Value Publish Status: 5302FF00
<t:     263081>, main.c, 2172, Status: 0 
<t:     263084>, main.c, 2174, -->Mesh send Telegramm: 5302FF0006E60000
<t:     263126>, main.c, 3235, Flash Data Param updated 
<t:     263129>, main.c, 3345, Provisioner continue Provisioning of nodes.....
<t:     263132>, main.c, 1101, Start provisioning procedure ...
<t:     263135>, provisioner_helper.c,  324, Provisioner helper INIT. 
<t:     263137>, provisioner_helper.c,  332, Scanning For Unprovisioned Devices
<t:     263167>, transport.c, 1045, Message decrypted
<t:     263180>, main.c,  729, Message from: 0x0001 
<t:     263183>, main.c,  730, Mesh Recieved: 5302FF0006E60000
<t:     263186>, main.c,  736, Received Mesh-------------------------Store in 0.
<t:     263190>, main.c,  737, Data received----------------------: 5302FF0006E60000
<t:     264036>, main.c, 2372, Filllevel mesh sendbuffer is---------------------------------------------: 2 
<t:     265019>, main.c, 2372, Filllevel mesh sendbuffer is---------------------------------------------: 2 
<t:     265023>, main.c, 2395, Segmentation part is: 0 and lenght 7 
<t:     265027>, main.c, 2403, tx_Send_Array Part 1: A700000000000000
<t:     265030>, main.c, 2156, Value Publish Status: A7000000
<t:     265054>, main.c, 2172, Status: 0 
<t:     265056>, main.c, 2174, -->Mesh send Telegramm: A700000000000000
<t:     265084>, transport.c, 1045, Message decrypted
<t:     265098>, main.c,  729, Message from: 0x0001 
<t:     265100>, main.c,  730, Mesh Recieved: A700000000000000
<t:     265103>, main.c,  736, Received Mesh-------------------------Store in 0.
<t:     265107>, main.c,  737, Data received----------------------: A700000000000000
<t:     266004>, main.c, 2372, Filllevel mesh sendbuffer is---------------------------------------------: 2 
<t:     266985>, main.c, 2372, Filllevel mesh sendbuffer is---------------------------------------------: 2 
<t:     266989>, main.c, 2395, Segmentation part is: 1 and lenght 7 
<t:     266993>, main.c, 2417, tx_Send_Array Part 2: B700000000000000
<t:     266996>, main.c, 2156, Value Publish Status: B7000000
<t:     267020>, main.c, 2172, Status: 0 
<t:     267022>, main.c, 2174, -->Mesh send Telegramm: B700000000000000
<t:     267038>, transport.c, 1045, Message decrypted
<t:     267056>, main.c,  729, Message from: 0x0001 
<t:     267059>, main.c,  730, Mesh Recieved: B700000000000000
<t:     267062>, main.c,  736, Received Mesh-------------------------Store in 0.
<t:     267066>, main.c,  737, Data received----------------------: B700000000000000

Call Stack:

- Could you try to reproduce the issue with the unmodified provisioner example ? 

I set it up, there is no issue in the lower regions (up to 20)

- Did you do any modification to the provisioner on how it store provisioning & configuration data  ? Could you check how much space the provisioning and configuration data for a node occupy ? 

I added some Files (as shown in the screenshot Post 1) each File more i loose provisionable devices. Example: with adding the 0xEE000 File the Provisionable nodes sink from 14 Nodes to 6 Nodes

in the File 0x0010 Page 0x0010 is the following change:

Unprovisioned: 6bytes, Provisioned 2 Devices 278Bytes = 136Bytes/Node

Edit:

I got the root of the error, Pointer seems not to be on valid target. after comment out the suspect part it seems to work for now.