Firmware Update from IOS

[Iskailko]

Hello,

after having a product using a nrf52832 MCU for a while in production using nrf connect sdk 2.5.1, we now wanted to supply a first firmware update. However, while the system was tested to work beforehand we now noticed that the firmware update (which we supply from our app) process, is extremly slow from IOS devices. It got to the point where it is pretty annoying to update from IOS devices for our customers. We are using an nrf52832 with external flash. The update process works also not very well from IOS devices using the nrf device manager app. The problem seems similar to the one posted here: DFU on iOS 17.3.1 nRF Connect app very slow. - Nordic Q&A - Nordic DevZone - Nordic DevZone But the solution does no longer seem accessible as for some reason I can set the number of buffers no longer to 2 (minimum is 3 in the app). 

Do you have any idea what the problem could be?

[Amanda Hsieh]

Hi Vito, 

Have you tried setting CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP? Does that help?

Does it also happen to the nRF Device on the Android phone?

Also, the device's flash is a limiting factor. If it can't write fast enough the data that is being sent over DFU / Bluetooth LE, increasing the number of buffers won't do a thing, since the flash will be a higher limiting factor. 

When it comes to the number of buffers: 

1. There is a "McuMgr Params" command in the OS Group in McuMgr that returns the number and length of available buffers on the fw side. The app just reads that and applies it.
2. One buffer is assumed to be for user outgoing notifications from the device to the phone. So if it claims 4, we use 3.
3. The command also provides the length of the buffer. This allows sending longer SMP packets than the MTU allows. They are later reassembled on the device side. This saves quite a lot of time, as the SMP Header is 8 bytes per packet + some CBOR wrapping. 
4. If the command is not supported, the buffer size defaults to ATT MTU-3. Make sure it's "big". The bigger, the faster DFU. 498 recommended.
5. The number of buffers can be set in code and override the McuMgr Params response if not supported. 
6. Mind that it is the device that has to have the buffers in the configuration. The settings in the app should reflect the actual state. One can't set the number of buffers in the app to 123 and expect the transfer to be immediate.

It would be great to provide logs from the McuMgr library on iOS. They should be produced in Xcode in your app. We would also like to know what the nRF Connect Device Manager app shows in the Device section at the top. It lists the params there.

Regards,
Amanda H.

[Iskailko]

Thank you for the answer. 

I cannot use this: CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y because I get RAM overflow on the nrf52832. 

The problem does not exist from Android Phones. There the nordic device manager app and our own implementation works as usual and at a decent speed. That's why I think that everything is fine with the external flash.

Here is a screenshot of the device manager on IOS app being connected to our device. I will also ask for the complete logs from the McuMGr library. It might take some time as I will have to get back to our app developer. For now I go this information from him, that he obtained from the logs: 

"Before the upload, the device communicate infos with the app. 

• McuMgr parameters 
  • Buffer SMP (2 x 2475)
  •  takes 2s (quite normal)
• Bootlader name 
  • MCUBoot
  • takes 20s (not normal at all)
• Bootlader mode 
  • Swap without scratch
  • takes 20s (not normal at all)

 

• The upload speed is more or less 0.6 KB/S"

Furthermore I checked the logs that I get from my device during the firmware update using 

CONFIG_MCUMGR_LOG_LEVEL_DBG=y

CONFIG_MCUMGR_TRANSPORT_LOG_LEVEL_DBG=y

The major difference I saw is that IOS negotiates immediately during connection an MTU of 185 and also uses this during firmware transfer:

IOS log output during transfer

"<\n>D: collect = 1149<\r>
<\n>D: started = true, buf len = 182<\r>
<\n>D: buf = <\r>"

While the android transfer does not negotiate a new mtu after connection but uses a much larger buffer:

Android log output during transfer

"<\n>D: collect = 1483<\r>
<\n>D: started = true, buf len = 495<\r>
<\n>D: buf = <\r>"

I also just realised that from my newer devices using nrf54l10 the device manager app has no trouble displaying Bootloader Name and Mode. Could a problem be there? As our own app already takes very long simply starting the update waiting for the bootloader name and mode. 

[Amanda Hsieh]

You only share logs from the DK's side. We also need the logs from the App side. You can get the logs via the icon  on the top right of the nRF Device Manager. These logs can be exported. Also, the logs can show more information by tapping "Level" and setting it to Debug. There's more information there from the library (app) side.

[Iskailko]

I dont have this Icon in the IOS device manager app. I have it only in the android app. There it leads me to the nrf logger, but I cannot find the nrf logger in the Apple Store.