DFU compatibility for a mesh example

[DeveloperZ]

Hi,

I am interested to know how to make a mesh node (for example, a light server) compatible to perform a DFU.

I have gone through the DFU page and I noticed that the DFU is done over the Serial port. I understand that the dfu firmware is being replaced with blinky firmware. Correct me if I am wrong.

Now, what changes should I make to the commands inorder to make the light_server example node to be DFU compatible/capable over the air?

Would replacing the application hex file on step 8 to light_server instead of dfu solve it? or should I add any other commands to have light_server firmware first?

Thank you.

[DeveloperZ]

Yes, There is a Mesh assert while loading the new firmware!!

The logs were:

<t:      15314>, main.c, 1112, Initializing and adding models

<t:      20203>, app_error_weak.c,  109, Mesh assert at 0x0002F696 (:0)

After the assert is occurred, I was trying to program the boards with the same firmware without erasing the board using Segger and it was showing the same error!!

When I erase the board, I can program the firmware successfully. 

Similar issue persists with all the examples to which I added the DFU capability. I can push the Blinky successfully but not the customized mesh examples :( 

To add, I used the DFU example/example to which I added DFU capability and pushed light switch server onto the board and it was pushed successfully.

Good news is that I traced out where the problem is occurring... 

It is happening in app_flash_init() function... and the exact location is shown in the figure below in the flash_manager.c file:

The second nrf_mesh_assert() is causing the error when it is checking if the flash area is valid.

We are storing some information in the flash like enocean data and few others. Is that causing this error? 

[Edvin]

DeveloperZ said:

We are storing some information in the flash like enocean data and few others. Is that causing this error? 

 Well. If you try to modify an example to not store this information, and that works, then yes, that is probably causing the error. How (and if you know, where) are you storing the enocean data?

And since you add this data somewhere, have you modified any defines in sdk_config.h or nrf_mesh_config_app.h to make sure that the rest of the application handles this data properly? (i.e. doesn't try to use that flash area for something else?)

Best regards,

Edvin

[DeveloperZ]

Edvin said:

How (and if you know, where) are you storing the enocean data?

I am using the stock enocean example. I don't exactly know the location where the data is being stored. I am pretty sure that the enocean switch information isn't causing any problem as I added DFU functionality to the enocean example and pushed the dfu packet successfully.

Regarding the other data that is being stored, we are storing them using random entry handles like 7EFF and 5EFF(which we assumed are the memory locations on flash). 

Edvin said:

And since you add this data somewhere, have you modified any defines in sdk_config.h or nrf_mesh_config_app.h to make sure that the rest of the application handles this data properly?

No, we didn't make any changes to those files. 

Where is the DFU data being stored on the flash? I mean, are there any specific locations defined to store the DFU data or is the data that we are storing interfering with the DFU data? 

Should we increase the flash page count on nrf_mesh_config_app.h to resolve the issue?

[Edvin]

DeveloperZ said:

Regarding the other data that is being stored, we are storing them using random entry handles like 7EFF and 5EFF(which we assumed are the memory locations on flash). 

 what do you mean by "entry handles"? Are you using FDS to store this data? Or perhaps fstorage?

[DeveloperZ]

Edvin said:

what do you mean by "entry handles"

It is the same way that you guys store the Enocean data in the enocean example. Create an entry handle and use app_flash_store, app_flash_data_store, app_flash_clear functions to write into and erase the flash.