Hello Nordic Semiconductor Team,
I have a device which uses the buttonless dfu bootloader / app design. And now i have some issues with updating the firmware with iphones and NRF connect.
If i connect with NRF connect on iphone (version 1.8.8) and start a DFU update. The app just stays on "connecting" and i can see from the LEDs on my device, that the device did not go into bootloader mode. After some time the app says: "Device disconnected unexpectedly" . (But the device is still in the normal application, according to the leds).
If I then press the "play"/ start button again the device correctly goes into bootloader mode and the update proceeds correctly.
If i use the NRF toolbox app it always works the first time. Also on android it works fine with both nrf connect and nrf toolbox.
So is there something wrong in the current nrf connect app on iphone ? Or is there some issue with my firmware which only shows with nrf connect on iphone ? Or maybe the DFU library is different ? What DFU library version is used in the NRF connect app (NRF toolbox shows the version number, but nrf connect does not).
It could be an issue with the Attribute table cache on the phone. You can try to test by turn off/on Bluetooth on the phone. Or you can try to change the BLE address of the nRF device just to be sure it's not because of the Attribute table cache (it's the issue when you change the attribute table but the phone won't do service discovery to update the table).
If that doesn't help, please capture a sniffer trace so we can investigate what happens over the air.
I just did a sniffer trace of this issue. And it looks like it really is this issue with the attribute page.
In the first attemt the phone seems to want to access handle 0x0089 which failes as it does not exist. (Attribute Not Found) and then NRF connect does not issue the write to the reboot characteristic and nrf connect just sits there, waiting for the bootloader.
In the next attempt it somehow has much less attributes to explore and thus does not fail and correctly issues the write to the reboot characteristic.
I put those two capture in the following link so you can see yourself:
So the question is now, what can i do to work around this issue ?
The sniffer trace iphone_dfu_fail2 looks a little bit strange. I can see there were a lot of CCCD characteristics has been discovered, all the way from handle 0x0011 to handle 0x007b. The error response to 0x0089 attribute not found is normal as it's the end of the table.
But we need to know what's your attribute table look like before and after DFU. Do you have a lot of attributes (services and characteristics) ?
Is it reproducible to get the failed trace ? How often do you see it ?
According to the sniffer trace, I assume you have service changed characteristic enabled ?
If you test with the default bootloader and default buttonless example, do you see the same problem ?
The device has 3 services. The Secure DFU Service, the Device Information Service and my Custom Service.
The Custom Service has many characteristics (about 35 and some of them are big (>200bytes). But i do not think this is the issue, as i tried a test-version with only one characteristic and the problem still persists.
With my firmware i can reproduce this error very reliably. It happens always the first time i want to update the firmware. Then NRF connect goes into timeout, and if i press play again it works once. If i then disconnect and connect and try DFU again the same happens.
I also tried the default buttonless example, and with this it works every time. So it is very likely to be a configuration issue with my firmware, which causes NRF connect (only on iphone, android works fine) to not issue the reboot write.
I will try some more to maybe find which config values causes this issue.
Do you have any other ideas on what i could try ?
It would be easier to debug on a more simplified version of your service/characteristic. Try to test with the one with only one characteristic.
You can also test using the ble_app_uart and add DFU buttonless service into it, just to see if you can reproduce the issue with that. If you can then it's would be much easier here since we are more familiar with SDK's examples.