Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

bjorn-spockeli — Thu, 04 Aug 2016 12:44:57 GMT

Ok, keep me posted once revisit the issue.

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Thu, 04 Aug 2016 12:30:29 GMT

@bjorn-spockeli: Lately, I was busy with other tasks, so haven't had a chance to visit this topic. Hopefully, I'll soon revisit this topic. Thank you for your help.

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

bjorn-spockeli — Thu, 04 Aug 2016 12:26:45 GMT

@sidekick : Have been able to solve this issue or are you still having problems?

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

coatix — Wed, 15 Jun 2016 10:08:18 GMT

I tried to achieve the same feat: buttonless dfu with a custom board while preserving bonds with the 51822QFAA (256kB flash 16kB RAM) using SDK 10.0 SD 8.0 . I guess that my main problem was to determine what to put in the memory areas of the options dialogbox. Here is what I have for both bootloader:

and target:

My major problem was to omit the noinit section, which is used to pass the bonding parameters from the application to the bootloader.

I used the stock bootloader from SDK 10 with the following changes:

In file ble_dfu.c line 180: changed:

BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);

to:

BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&attr_md.write_perm);

To restrict acces to the dfu process

In bootloder_settings.c (line 18), added const and = {BANK_VALID_APP}; to make sure that I can download a merged hex (bootloader and application)

In dfu_types.h, line 56:

#define DFU_APP_DATA_RESERVED           0x1000

as mentionned by Bjorn

In main.c, line 154, changed the SD init to use the internal RC instead of the crystal:

SOFTDEVICE_HANDLER_APPSH_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_4000MS_CALIBRATION, true);

I also commented all references to leds and buttons as you did.

In both pstorage_platform.h (bootloader and app) line 30:

#define PSTORAGE_NUM_OF_PAGES       3

I don't know if it is mandatory though...

In doing so, I can upgrade my application without losing bonds using my iphone. However, I have to restart bluetooth (ON->OFF->ON) on the iphone before it works. I know that I haven't lost the bonds because my application won't reconnect othewise.

Good luck !

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Mon, 06 Jun 2016 12:36:52 GMT

@bjorn-spockeli: Can you please give some more pointers ?

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Fri, 27 May 2016 08:04:08 GMT

This time, I tried DFU OTA (BLE) over a bonded link with Keep bond information in the MCP android app as ON and I get a hardfault after OTA completes. Since there is no option to attach a file in the comment section, hence i'll be attaching the central and peripheral logs in the original question section. Please advise.

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Tue, 24 May 2016 11:52:58 GMT

No problem and thanks a lot for helping me out with this issue.

Update:

As you suggested, I changed, DFU_APP_DATA_RESERVED to 0x1000 in dfu_types.h (corresponding to· PSTORAGE_NUM_OF_PAGES of 3 in pstorage_platform.h). Also I'm not calling pstorage_register anywhere in my application code.

Result:

Bond gets deleted after the upgrade process.

Question:

1: I'm using Nordic's Master Control Panel (MCP) app for Android phones for performing firmware upgrade, and I see that there is a option to "Keep bond information" under the setings-> DFU options. At the moment (I think this setting is by default) this is turned OFF, should I turn this ON ?

2: As I mentioned before, I'm using Softdevice v8.0 with SDK 10.0.0 and to generate the application zip file that contains the application hex image. I used sd_ble_version_get() to find the softdevice version (ble_version_t.subversion_number) and then used nrfutil.exe to generate the zip file as below:

$ nrfutil.exe dfu genpkg --application myapp.hex --application-version 0xffffffff --dev-type 0xffff --sd-req 0x64 myapp.zip

During DFU-OTA process, I select, the file type as "Distribution packet (ZIP)" and pass this zip file that (myapp.zip) I created before. Is this correct method ?

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

bjorn-spockeli — Tue, 24 May 2016 07:35:13 GMT

@sidekick: I sincerly apologize for not replying sooner. If you have set PSTORAGE_NUM_PAGES to 3, then you'll have to set DFU_APP_DATA_RESERVED to 0x1000. What I mean by "If you're not using the Persistant Storage Manager", is that you're not using it to store application data, i.e. calling pstorage_register from the application.

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Fri, 20 May 2016 14:39:53 GMT

Update: 20.05.2016

Bootloader:

IROM1:0x3C000 (0x4000)
IRAM1:0x20002C00 (0x1380)
IRAM2:0x20003F80 (0x80) No Init box checked

Application:

IROM1:0x18000 (0x24000)
IRAM1:0x20002000 (0x4000)

Following are some defaults in my application code:

#define DEVICE_MANAGER_MAX_APPLICATIONS  1
#define DEVICE_MANAGER_MAX_CONNECTIONS   1
#define DEVICE_MANAGER_MAX_BONDS         7
#define DM_GATT_CCCD_COUNT               4
#define DEVICE_MANAGER_APP_CONTEXT_SIZE    16

Q.1: How to calculate DM_GATT_CCCD_COUNT and DEVICE_MANAGER_APP_CONTEXT_SIZE?

In my bootloader code, I'm setting following in dfu_types.h

#define DFU_APP_DATA_RESERVED           0x400

My application currently does not try to store anything in the flash by using persistent storage manager, however, the application uses device manager which internally uses persistent storage manager, therefore as suggested before, I've set this macro (DFU_APP_DATA_RESERVED) from the default 0x0 to 0x1000. ( pseudo random number based on suggestion)

Result:

DFU while devices are bonded works fine, but bond gets deleted once DFU finishes :(

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Thu, 19 May 2016 13:54:15 GMT

@Bjørn, Meanwhile, I'm not able to understand what you meant by this "If you're not using the Persistant Storage Manager" Isn't device manager implemented using persistent storage manager ? i.e. If I need to retain bonding information, i need to use device manager and using device manager implicitly mean using persistent storage manager. Even the sample routine "device_manager_init() invokes "pstorage_init()"

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Thu, 19 May 2016 11:40:21 GMT

Update

In the presence of bootloader whose start address is 0x3C000 On my 256 KB version of NRF51822 SOC, the IROM1 field for the application should be as:

IROM1: 0x18000 (0x24000)
IRAM1: 0x20002000 (0x4000) <--- same as before

Since, the application data, swap data, and device manager all part of application area(correct me if i'm wrong), IROM1 for application should be starting from 0x18000 until the start of bootloader start area (0x3C000)

Also, updated PSTORAGE_NUM_OF_PAGES to '3' (device manager + application data, + swap data) in application specific pstorage_plafrom.h

Result: DFU fails everytime (MCP error log: [DFU] Connected: DFU Service not found.)

After this, I do a power cycle (since, the peripheral seem to be stuck somewhere and is not even advertising anymore) and then the peripheral shows up in MCP as bonded device.

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Wed, 18 May 2016 15:48:49 GMT

Persistent manager:  one page.  
Application data: one page (For future purpose)
Swap : one page

Therefore, I'm now setting DFU_APP_DATA_RESERVED to 0xC00 (Note that dfu_types.h is not included in application, hence It is only relevant when building booloader) and hence the IROM1 size value for application has been adjusted to (0x3C000 - (3 * 0x400)) - 0x18000 = 0x23400.

But with this configuration, If i start DFU after connecting (no passkey) --> bonding --> initiating DFU (using MCP andorid app and using a .zip file containing only application), central gets disconnected in the middle of DFU and from here I re-issue DFU, which works, since the system is now in Bootloader mode already (This is the new behavior). This is even worse, as it fails in the middle of DFU and I still could not retain Bonding. All other configurations are same

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

sidekick — Wed, 18 May 2016 15:25:46 GMT

@Bjørn, Thank you. I was busy doing some other stuff and hence coming back to this topic after a while. Today I tried as you suggested, and it hasn't worked yet (actually, I'm getting into another issue). So the first thing I did was corrected memory partitioning for Bootloader and application. For bootloader:

IROM1: 0x3C000 (0x4000) <-- 16 KB for Bootloader
IRAM1: 0x20002C00 (0x1380)
IRAM2: 0x20003F80 (0x80) No Init box checked

For application:

IROM1: 0x18000 (0x23400)  <-- this was incorrect before
IRAM1: 0x20002000 (0x4000)

Numbers in parenthesis represent size.

As of now I'm doing Just works pairing (Central is able to connect to the peripheral without being asked to enter any passkey) and then I do the bonding. To enable bonding, I'm using persistent storage manager. <reached size limit, continue in next comment>

RE: Bonding issue with DFU BLE on custom board with SDK v10 and SD v8.0

bjorn-spockeli — Tue, 12 Apr 2016 07:47:50 GMT

In order to retain the bonding data during a DFU, you have to change the value of DFU_APP_DATA_RESERVED in dfu_types.h, the default value is 0x0000.

#define DFU_APP_DATA_RESERVED           0x0000

The value refers to the to number of bytes below the Bootloader start address that should be retained. Thus, in order to retain the bonding data you have to set it as shown in the picture below. Please note that the figure assumes that you use the Persistant Storage Manager.

If you're not using the Persistant Storage Manager, then you should only have to set DFU_APP_DATA_RESERVED to 0x400, i.e. one flash page.

For more information see this Infocenter page.

-Bjørn