[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

[Aaron]

SDK 14.1 has a fix for a bug that would otherwise prevent you from updating the SoftDevice, so you'd definitely want that one. Also, make sure your new bootloader fits in the same size as the old one, the UICR bootaddr can not be changed. Also, be aware that updating the SDK is a more painful process than you might think, they do not make changes backwards compatible. Not a Nordic Engineer, but recently gone through the process of updating to SDK 14.1. Although looking at it recently there is a 14.2 out now, I supposed you'd want to update to that.

When using the buttonless DFU service in 14.1, there is a second, undocumented init function you have to call or else recent nRF Connect iOS update will not be able to update your device. See devzone.nordicsemi.com/.../

[Bjørn Kvaale]

I agree with @Aaron , I would definitely upgrade to SDK 14.1. You can read up about a bug on SDK 14 here. Just curious, are you using nrf52 dk's as your devices? Also agree that the DFU process can be tricky, so think hard before you start. If you really need the OTA DFU Buttonless feature, it would be a good idea to upgrade, as the 14.1 version is more stable than the one found in SDK 12.2. If you decide to start, give it a try & you can either update this thread or create a new case on devzone if you run into problems.

[trdop]

Thank you both for these interesting and encouraging returns I will actually go to version 14.2 directly!

I think it should be okay to be attentive, to tell the truth the most scary thing is this Bootloader story and memory slot allocation !

@Bjørn, after I use the DK52 , but now I turn on our device that was built around the nRF52 also

[Bjørn Kvaale]

Good idea! Good luck! And just update this post or create a new case if you run into problems.

[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 ?

---