[SDK 7.2 DFU] Adding DFU service at NUS example

[MANGO]

• SoftDevice : S110 7.1

• SDK 7.2

• Example : nrf51-ble-app-temp + experimental_ble_app_uart

• Using IAR 7.1

• (Before debugging with IAR, I downloaded both the bootloader.hex and s110 7.1 hex with nrfjprog.exe)

• Modified SDK files : bootloader_util_arm.c (copied asm code SDK 8.1 since I use ICCARM, )

• Using nRFGo Studio 1.19.0

• Board : PCA10001 V 2.0.0 (Rev. 2 MCU)

• Test device : Nexus 5 (Android 5.1.1) and iPhone 6+ (iOS 8.4)

• Toolbox App Version : 1.14.1 (at Nexus 5) & 2.1 (at iPhone 6+)

/*****************************/

Hi, I added the DFU service at the NUS example.

After I checked the firmware(NUS + DFU) starts the bootloader, the connection gets lost.

I tried to send the ble_app_hrs_dfu_s110_v7_1.hex and init file.

(The hex file and the init file or the .zip file I'm saying is the one at the app as default.)

The bootloader called static void wait_for_events(void) in bootloader.c.

However, where was a problem at checking the crc.

So what I thought was,

comparing with the HRS example that includes DFU has the bonding info.

At the link, it said that

If sharing of bond information is shared from application to DFU,
 directed advertisement is used and only the bonded peer will be able to connect.

So, the HRS example bonds again with the central (such as iPhone)?

Whereas, the NUS pairs with the central, so it has to do a direct advertising, does it?

Then when I use the NUS example, shouldn't this

if (crc != m_peer_data_crc)

be not true?

I checked the thread from Stefan Birnir Sverrisson

but I don't understand why the the CRC causes the problem.

Or is it something else?

Added 18, July, 2015 : I tried the Master Control Panel (version 3.9.0, 32bit at 32bit Windows 7 SP1).

Since the DFU FAQ section G says that

Note that on MCP v3.9 we can select the hex file directly,
the .zip will be automatically generated. 

so I just selected the hex file.

I tried it with the same hex file and init file using my Nexus 5 (Android 5.1.1 MCP 3.2.0).

Comparing with the HRS + DFU example, this example's DFU version is not 0.1. It is 0.5.

It failed, but the connection with the bootloader (DFUTarg) was not disconnected.

I noticed that when using the MCP Android app,

at wait_for_events(void) (bootloader.c),the loop iterates 11 times.

When using the iOS Toolbox App, it iterates only once.

Each iterations, the value of m_update_status was 0 (BOOTLOADER_UPDATING).

The firmware's program counter stays at the bootloader.

Did the log message gave enough info?

So, after showing GATT error message, the program counter is pointing the codes of the bootloader.

And when I try DFU again, it works. However, I want it the DFU to be successful in one shot.

To be more specific, I used the nrf51-ble-app-temp example.

I removed the HRS part and added

case BLE_GAP_EVT_SEC_PARAMS_REQUEST :
case BLE_GATTS_EVT_SYS_ATTR_MISSING :
case BLE_GAP_EVT_AUTH_STATUS :
case BLE_GAP_EVT_SEC_INFO_REQUEST:

at on_ble_evt function by copying the contents at the NUS example.

I also use the scheduler.

-Regards, Mango922

[Hung Bui]

@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

[MANGO]

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.

[Hung Bui]

@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

[MANGO]

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?

[Hung Bui]

@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.