[SDK] Switching our project from SDK12.2 to SDK14.0

[trdop]

Hello Nordic team,

I just post a message here to take the temperature, and your respective engineering opinions about that…

It's been a few months that I work on the development of our IOT and we have therefore chosen, and been well advised, for our Bluetooth base to go with Nordic, very good choice as much for the quality of the SDK, the Chip and the ecosystem.

A few months ago, I started to go on the SDK12.2, our device is functional as such and we use roughly the following stack:

• ANCS
• UART/NUS
• DFU Button Less
• Libs for MEMS

But, for example, there is some of this: one of your engineer, in the past, told me in a post (devzone.nordicsemi.com/.../ >> "Q2") that I was lucky that the buttonless DFU works because it was clearly still unstable on the V.12.X… and also, just recently, I have discovered a nice x7 consumption bug of the electric current after making a division floating in my code (devzone.nordicsemi.com/.../) that I saw to counteract serious to this little hack in the power_manage(void)

As we wanting to incorporate some new feature into our existing code (send HID frames to our device connected to our IOT Object) and at the same time incorporate DualBank OTA and also make some TimeSlot (broadcast beacons frames at the same time we are in connected mode with an iOS ...)

It come to me that it's maybe the right time to migrate all our SDK12.2 code on the new SDK14 (I read somewhere that the DFU OTA Buttonless had finally arrived at maturity of production)

—> Do you see obstacles to this move, pitfalls to avoid or points of friction on this transition?

So It should update, for this next OTA which will therefore be done in 'Button Less' update on our existing devices at our customers, the three layers :

Bootloader + SoftDevice + App,

—> Will be there any problem with that?

—> Do you recommend the version SDK14 or SDK14.1?

Thank you for your estimates and have a good day

[trdop]

to follow up and report an important blocking point, before me putting that on MyPage…

————> I took the last example of IOS-Pods-DFU-Library v 4.0.3 with that I make sure my BL SD APP + (settings 4 Factory) v.12.2 -> V.12.2 without problem: OK

————> I took a simple example ANCS v.14.2 and I grafted DFU with that I get my BL SD APP + (Settings 4 Factory) v.14.2 -> V.14.2 without problems: OK

————> now when I want to make the OTA of my device in the nature that are on the SDK 12.2 So BL SD APP + (Factory Settings 4) v.12.2 -> ANCS + DFU V.14.2

This is what happens: (see in screenshots: animated GIF)

• 1st pass: OK
• 2nd pass: NOK > "Error 305: Writing to characteristic failed!"

---

Do you have ideas, because before advancing more in the migration I would naturally test and validate it in the state! and also I saw in the bootloader sdk_config.h v14.2 option BOND what it is?, it is set to false but if I put it to true what will concretely change? I have a little trouble understanding, in that case?

In any case if you can help me or give me a track to follow about the error with characteristic not written when DFU it would be great! Thank you

What I find odd too is when I use the latest version, to make my OTA from 12.2 to 14.2 with "nRF Connect.app" on iOS, instead of my Adapted IOS-Pods-DFU-Library example to make the OTA, it's directly puts a message alert that can not find DFU Service? and don't even go in the 1st pass which was "working" at least previously with IOS-Pods-DFU-Library example, would it be a source of ideas ?

---

[Bjørn Kvaale]

Hi trdop. Sorry for the delayed response. I have taken a look at your question for a while now and am unsure as to why this issue is occurring. I think it is best if you post this question on Nordic Mypage (you can link to this devzone question in your mypage question). Have a nice day!

[trdop]

On this issue, the Nordic engineer recommended and informed me that: The bootloader does not use the nrf_sdh_ble_default_cfg_set() function while enabling the stack, so the sdk_config configuration is not applied, and the softdevice seems to enable SC by default.

so for those who have this issue, add the following else statement in ble_stack_init [ nRF5_SDK_14.2.0_17b948a/components/libraries/bootloader/nrf_ble_dfu.c ] :

#if defined(NRF_DFU_BLE_REQUIRES_BONDS) && (NRF_DFU_BLE_REQUIRES_BONDS == 1)
    NRF_LOG_DEBUG("Running Service Changed config");
    ble_gatts_cfg_service_changed.gatts_cfg.service_changed.service_changed = 1;
    err_code = sd_ble_cfg_set(BLE_GATTS_CFG_SERVICE_CHANGED, &ble_gatts_cfg_service_changed, ram_start);
    VERIFY_SUCCESS(err_code);
    NRF_LOG_DEBUG("Finished running Service Changed config");
#else
    NRF_LOG_DEBUG("Running Service Changed config");
    ble_gatts_cfg_service_changed.gatts_cfg.service_changed.service_changed = 0;
    err_code = sd_ble_cfg_set(BLE_GATTS_CFG_SERVICE_CHANGED, &ble_gatts_cfg_service_changed, ram_start);
    VERIFY_SUCCESS(err_code);
    NRF_LOG_DEBUG("Finished running Service Changed config");
#endif

It works very well on several tests on my side!

[Bjørn Kvaale]

Great to hear! Thanks for updating this case! :)