[SDK 7.2 DFU] Adding DFU service at NUS example

RE: [SDK 7.2 DFU] Adding DFU service at NUS example

Hung Bui — Tue, 21 Jul 2015 07:56:43 GMT

@Mango: Yes we will check it to know if the peripheral is application or is the bootloader. If it's the application, it will try to trigger the device enter the bootloader first, then start sending image.

RE: [SDK 7.2 DFU] Adding DFU service at NUS example

MANGO — Mon, 20 Jul 2015 15:59:39 GMT

Really? After I unzipped the SDK 7.2, I used that ble_app_hrs dfu example. Well I will check it.

Added 21, July, 2015: You're right. In the example,

#define DFU_REV_MINOR                        0x05

was defined like this. Thanks to you, it works now.

Before closing the question, does the MCP App or nRF Toolbox check this DFU_REVISION value

whether it is 1 or not?

RE: [SDK 7.2 DFU] Adding DFU service at NUS example

Hung Bui — Mon, 20 Jul 2015 15:37:23 GMT

@Mango922: If you test with our ble_app_hrs s110_with_dfu example, would it work ?

The DFU revision in the app should be 0x01 not 0x05 as in your screenshot (the last charactersitic, with the value 05-00)

So for the app (NUS+DFU) revision should = 1 , for the bootloader (DFUTARG) revision should = 5. It's defined by DFU_REVISION in main.c in our ble_app_hrs dfu example.

ble_app_template on github is pretty old, please use the template in the SDK v7.2

RE: [SDK 7.2 DFU] Adding DFU service at NUS example

MANGO — Fri, 17 Jul 2015 12:34:24 GMT

I didn't know there was a example of a buttonless bootloader example. Anyways,

the hex file and the init file I use is simply the ones that already existed at the App.

When there's nothing at Memory 0x16000, the Toolbox app has no problem doing the DFU.

So, for your bolted question, I'm sure that when the firmware has only the bootloader, it can update (or receive) the hex file and init file from the app.

However, after downloading the modified (NUS + DFU) example, even though I used the

hex file and init file which were already existed in the app, it failed.

I will try the nRF Master Control Panel and check the logs.

RE: [SDK 7.2 DFU] Adding DFU service at NUS example

Hung Bui — Fri, 17 Jul 2015 10:58:20 GMT

@Mango922: If you haven't bond with the device then it's normal that the crc check is failed. But it should not cause any trouble because the result of dfu_ble_get_peer_data() is just to set m_ble_peer_data_valid = true; or not. You can have a look at dfu_transport_update_start() in dfu_transport_ble.c file. So if crc check failed, we will simply not use bonding.

The issue should be with something else, have you made sure you can update the hex file and the init file normally (straight with the bootloader, without using button less example) ?

I would need you to attach:

Log file from nRF Master Control Panel app when doing DFU (swipe right)
Sniffer trace