How to extend mesh light_switch example with DFU

[rolliG]

I am using the Mesh-SDK v1.0.0, the device is the nRF52832xxAA on PCA10040-Boards with the Softdevice s132. I am new to the development with BLE, and specially mesh. I have successfully done the DFU example, the application won't work, but the DFU looks like it was ok. Now my qestion:

1. How could I extend the light_switch example to be DFU-ready? (primary target)
2. Why is the example binary (app_green_s132.hex), which was a part of the DFU exmaple not working? (The board just stops working after the DFU) Is there any sourcecode for this application? Is inside the app_green.hex a build in DFU-functionality, to upgrade this app to a new version?
3. Somwhere in the documentation stands, that the DFU functionality from the bootloader will be used for the application, how many space is needed in addition to lets say the light_switch-application to implement the DFU functionality? (I tried to update the DFU example with the examlpe itself, but the firmware looked to be too big, i've got a error message at the start of the download "Abort event. Reason: 0xD").
4. Is there some documentation about the porting of the DFU functionality inside a mesh-application? Or the usage of the bootloader DFU inside the mesh-pplication code?

[Bjørn Kvaale]

Hi Roland,

After a successful DFU, the application should start automatically, so I don't think your DFU was successful unfortunately. 

Question 1: I would firstly get the DFU example to work. Then, I would take a look at the light switch source code (client & server) & compare this with the DFU source code.You can make a copy of the light switch example folder (under mesh_sdk/examples/) & call it light_switch_dfu for example. Then, try to add the DFU functionality into this new example by adding the functionality available in the DFU example that is not available in the light switch example. It will most likely help to really understand all of the code and all of the steps needed to setup a mesh network. 

Question 2: Taking a look at the DFU quick start guide, it seems they use the blinky example instead. Could you try running the DFU with this example & follow the steps in the DFU quick start guide & see if that works?

Question 3: Are you referring to this?

Question 4: It might be helpful to have a look at this link & use the Secure DFU application in the normal Nordic SDK. Also, take a look at the DFU quick start guide I mentioned in Question 2 & maybe this blog post will help.

Hope that helps!

[rolliG]

Hello,

thank you very much for the answer. I would like to clarify my questions a little more...

Question 1: The new mesh-sdk (1.0.1) looks very optimistic, I had few sucessfully updates, but sometimes I get the 0xD and a abort, this happens on different update zip files. Also the initial update fails sometimes, I don't know why. Maybe I have some errors in the build procedure of the devicepage or the update zip file itself. Would have a look at them? Should I send them to you?

Question 2: Now I have some successes on the new mesh-sdk. So I got some hope, that all will be fine, but one more thing don't let me sleep pacefully, look at the Question 3. point.

Question 3: I refere to the README.md file in the sdk 1.0.1 in the subfolder /mesh/bootloader. I got a device with BLE, with the normal SDK and a booltoader, this device is in production and no changes should be made, now I would like to make a DFU with a new Softdevice and a mesh-functionality. So I have to change the bootloader, to get the full mesh functionality. The usual bootloader erases the application, updates the softdevice and the bootloader. Now I have a dvice with no application. In the README.md from the booltoader under the point "## Side-by-side DFU" is stated, that "The bootloader is also capable of operating without an application, as a recovery mechanism from a faulty application." but under the "## Limitations" you could find the note "- The bootloader is not able to host a DFU transfer on its own, it depends on an external entity initiating and controlling the transfer." Could you tell me please which of the two statements is true?

Question 4: Now I have some more overview, I will hope I get it to work, if I got the other things to work.

I am looking forward to hear from you.

[nikunj8086]

hi rolliG,

i am doing same thing to test mesh dfu example with mesh sdk v1.0.1

but i am not able  to generate device page after i added public key in to json file.

this is my json file look like.

{
    "bootloader_config": {
        "bootloader_id": 1,
        "bootloader_version": 1,
        "company_id": 89,
        "application_id": 1,
        "application_version": 1,
		"public_key" : "34fdf55c448c77577f69e2969189d946cabf9aaefdce3cacf64e4dbd4d10781d67ccc090838cc43ea3c3e6f91c0646b538e33656733c98a80a7d1ea65697ec9e"
    }
}

please let me know where i am getting wrong.

[rolliG]

Hello nikunj,

this is a problem, which I have also, but I have taken the debug version of the booltoader, which do not check the signature, so I have postponed this problem. The json you have posted looks just like the one in the documentation. And it won't work. There are some another thingies, which didn't work as promised (the tooling for mesh isn't compatible with the ble sdk, the bootloader have many versions, not all of them work togehter with all tools). My wish were to get maybe more smaler tools instead of one tool far all, so maybe someone with python skills could repair it a little bit easier, and another one, it would be great, if the tools would be released with the sdk releases, this would be make the life much easier.

[ketil]

Hi,

Do you still have problems with device page/dfu? Could you please create a separate case?

Ketil

[nikunj8086]

now i am able to create using python 3 and devicepage_genereator.py from sdk 1.0.1.

any way thanks 

[ketil]

Great. Thank you for letting us know.