Unable to DFU the bootloader and new soft device, Android library works.

[meoster]

Unable to DFU the bootloader and new soft device, Android library works.

Try to OTA a new firmware with a new softdevice. (HomeKit sdk user guide 7.2.6) Unable to flash using the iOS library. Android version is ok however.

Homekit SDK 4.1.0

Both our firmware and the door lock example is failing.

[meoster]

Homekit SDK 4.0.1 was ok.

[meoster]

Homekit SDK 4.1.1 lock example 1.2.3 to dfu 1.2.5, 1.2.6 under the hex directory is not working for nRF Connect and nRF toolkit

I am unable to test our own app using this github library until next week. Would like to get any feedback from you before I do.

Android nRF toolkit works.

[mostafaberg]

1- First feedback is to stop testing it against Android, HomeKit has no reason to be tested on Android.

2- iOS caches characteristics and services for homekit and BLE, make sure you are invalidating that by bumping homekit configuration version and having CCCD on BLE.

3- Please clarify more what you mean by "not working", we can't help without seeing logs and knowing your exact setup :)

if nothing of the above helps, please send us all your logs from both peripheral side and iOS Side and we can take it further

[meoster]

1. Gotcha, but we were desperate to upgrade our old code to 4.1.1. Remote developers are currently not able to test with the new bootloader.
2. Can you give more detail to this? Our firmware version is incremented already. I will look into CCCD for our own app, but currently the nRF app is not updating, I would think the notification is already enabled.
3. Just means the nRF iOS on app store can't update the firmware. Basically using iOS connect or iOS toolbox to update the sample lock app on the Homekit SDK 4.1.1. Going from 1.2.3 to 1.2.5.

[mostafaberg]

1. No worries !, the main problem with Android testing is that Android does not follow 100% all the standards and has more flexibility than iOS, so I seen lots of examples where things work for people on android and not iOS, but the correct behaviour was for it not to work at all as per the BLE specs.

2. Regarding the firmware version I actually meant the HomeKit Configuration version, not the firmware version, to see what I mean please download the HomeKit accessory protocol document and in bullet number 6.4.2.2 Manufacturer data CN is 8 bits and has to be bumped with every firmware update. if this is the same across firmware updates, things will not work properly. When it comes to CCCD you can check the Bluetooth spec here

3. I don't think nRFConnect will work out of the box, you better use the latest version of nRF Toolbox with Homekit DFU example, let me know step by step what you do and what happens in the app and your peripheral

[meoster]

1. Noted.

2. I read about that one (Manufacturing data cn counter. May be this is our problem). About CCCD. That's for enabling notification for call back right? Will look into that as well

3. We actually tried both. Toolbox did work better. But still not updating the full BL+SD+APP, note we had APP only dfu working before.

[mostafaberg]

2. Perfect !, No, the CCCD is to push changes to iOS when the GATT table changes on your peripheral, but you might not need to trigger the service changed indication, just having the characteristic present is enough to stop iOS form caching (note that this might cause the discovery to be enforced everytime you connect, causing delays), but this is a final resort :)

3. Hmm I see, i'm 90% sure it's simply a caching issue as this works locally, if not then it might be a minor bug in your Firmware, but we can debug that together when you have everything on your hands, keep us updated! and it would be nice to see the logs

[meoster]

2. Hmm, just check.. not the cn issue. The Homekit SDK does the increment automatically.

   // Only update and reset values if this is not the initial boot.
   if(version_from_pshandler != 0)
   {
   // An update has taken place. Update CN, GSN and BD_ADDR.
   // Also store the new version is flash so this is only done once the version is updated again.
   cn_handler_update_cn(p_cn);
   pshandler_bd_addr_reload();
   
   if(pshandler_cn_store(*p_cn) || 
      pshandler_version_store(current_fw_version) || 
      pshandler_gsn_store(&_acc, 1, false))
      {
          APP_ERROR_CHECK_BOOL(false);
      }
   }

   ---

   void cn_handler_update_cn(uint32_t * p_cn)
   {
   (*(p_cn))++;
   
   if((*p_cn) > 255)
   {
       *p_cn = 1;
   }
   }

[mostafaberg]

Hmm good to rule out those issues, now the final thing to look at is some logs, if you can attach the logs from the mobile app and the peripheral that would help us find the last part

[meoster]

yeah we are debugging now.
It seems to be some incompatibility with the latest 4.1.1 Homekit dfu with the ios dfu library. I am not able to buttonless kick the sample lock firmware into dfu at all. Old Homekit 4.0.0 we can do it.

The demo board DFU indicator LED would go on and off around 1 secs. Will try to dig the dfu code on v4.1.1. Please ask your homekit team to test also.

[meoster]

I think we figured out the problem.

1) v4.1.1 to v4.1.1 upgrade. (We tried to change the DFU name to do a unique upgrade.) We need to invalidate the cache. We will likely discard the idea, and go with your original flow. Since upgrading two device of the same type is acceptable.

2) We tried to upgrade SDK12 to SDK13 based DFU device. Seems like there are too many changes between the two. Hopefully SDK13+won't change too much in the future.

[mostafaberg]

Hi @meoster ! that's great news !

You are absolutely right about your points, SDK12 to 13 is not compatible, but anything after SDK13 is going to be backwards compatible with SDK13 so you won't have to deal with those issues again.

We are also having a new change in the next SDK that supports automatically generating a random peripheral name for you when you jump to bootloader and the SDK will handle the name automatically, it is already supported in our latest version of the DFU Libraries so it'll work out of the box when it's out. also SDK13 plus does a service change indications so you will no longer have caching issues in DFU either.

In case you didn't know, you can have a distribution ZIP archive that merges SoftDevice/Bootloader and Application in the same zip, you just need to put the contents of the manifest files into one manifest file and zip them all together, the library will handle restarting and flashing all your firmwares at once.

if this is resolved should I close the issue now ?

[philips77]

As far as i know, in the dfu bootloaders from SDK 12 the Service Changed characteristic was disabled by default, which was wrong. I've from SDK 13 had it enabled. This causes caching problems on iOS when doing anything update of the bootloader as the handle numbers are invalid and it's not possible to enable cccd for the dfu control point characteristic. If you want to make the update, you have to disable it on SDK 13 as well, ideally only for the first update. Otherwise, when sd+bl is updated, and the device restarts into the new bootloader, the ios uses cached services (as there was no SC) and second update will fail. Having SC enabled on the first place would have prevented from caching at all on not bonded devices (bonded secure dfu is supported since SDK 14) and such update would cause no problems. As the future update to SDK 14 would be in some time, there is a huge chance that the cache would be erased until then (Bluetooth restarted, phone restarted, etc) so following update with SC enabled this time would work.

To correct Mostafa, it's the presence of SC that's important, not the indication. Indications are sent only on bonded devices and were not supported before sdk 14. Also, it may be difficult to add bonding in an update now... But that's another story.

[mostafaberg]

Yes, sorry about the mistake, having the SC without bonding will tell iOS not to cache at all (This is out of the BLE spec though, but apple does it that way) but having it with bonding will cache until the indication is sent.

[meoster]

Thanks guys, yes, I think we can close this. Will test again when SDK 14 goes into Homekit R10 SDK.

[mostafaberg]

Perfect !, good luck, keep building great stuff :)