DFU with device manager app works and fails for particular versions of iOS.

[Phattaw]

Performing a DFU with an iPhone works in some configurations and fails in other. Android consistently works.

The failing version of iOS is:

iPhone 12 mini

iPhone 13 pro max

iOS v18.3.1

Device Manager version 1.9.1

The working version is:

iPhone 12 mini 18.2.1

Device Manager 1.9.1

This issue is very similar to the issue seen in case 338790.

[Phattaw]

We're not able to debug this and this has always worked on Android. Why is it different for iOS? What do I have to change for this platform?

If the image you try to download is in one of the ping pong buffers the dfu short circuits the entire process and just switches to the buffer with that image in it saving time on downloading unnecessary images by using what's already on the device.

[Vidar Berg]

Why is it not possible to debug this? I have not found any other reports that resembles this problem. I'm also using iOS and have not experienced the issue myself.

Phattaw said:

If the image you try to download is in one of the ping pong buffers the dfu short circuits the entire process and just switches to the buffer with that image in it saving time on downloading unnecessary images by using what's already on the device.

Maybe I'm misreading this, but doesn’t this suggest that the previously cached FW image was correct, while the new one might be invalid? You should see that the hash digest changes when you select a new image in the app.

[Phattaw]

Look at ticket 338790 I reference in this post. This is the problem with iOS and my image. I cut off investigating that issue because of what the app guy told me but he was mistaken that it had been fixed. I have the entire project attached with the source code and project files.

I can download 3 entirely different images using an android phone and they will all download and switch between them. This does not work with an iPhone. 

Do this to understand the ping pong buffer:

1) DFU a valid image to your device. You'll see device manager download and then load it.

2) DFU another valid image to your device. You'll see the same as 1)

3) DFU the image in 1) You'll see that there isn't a download but it will still say the image is complete and when testing you'll find that image is installed now. 

4) Repeat step 3) with the image from step 2). You'll see that there isn't a download but it will still say the image is complete and when testing you'll find that the second image is installed now. 

5) DFU a third image different from the other two. You should see it download similar to step 1) or 2). It will replace the oldest image (the image from 1) if you follow these steps).

You could now switch to the second image without a download. If you try and DFU the image from 1) you will have to download it and it will replace the oldest image. 

[Vidar Berg]

Thanks for the clarification. Yes, the app will automatically skip the upload if it sees that the hash digest of the image in the primary or secondary slot already matches the digest of the firmware binary it is about to upload. It will just mark the image as pending and have the bootloader swap the images again if necessary (given that there's no downgrade protection is enabled). But note that you can also used the "Advanced" view under the image tab in the device manager app. This gives you more control. It will for instance allow you to re-upload an image that is already present on the device. 

I tried to read the linked support ticket again, but I don't see anything to explain why the MGMT_ERR_ECORRUPT error is raised. These are the only two places that can return this error as far as I can tell:

https://github.com/nrfconnect/sdk-zephyr/blob/c0aa4d27d3f2767e88c6c8c4634425086156f7f5/subsys/mgmt/mcumgr/smp/src/smp.c#L310

https://github.com/nrfconnect/sdk-zephyr/blob/c0aa4d27d3f2767e88c6c8c4634425086156f7f5/subsys/mgmt/mcumgr/smp/src/smp.c#L317 

I also tried to reproduce the issue with the .hex and .bin file you shared on Jan. 23. without any luck:

My setup

Device Manager app v1.9.2

Iphone 12 pro max running ios 18.3.1

 

[Aleksander Nowakowski]

Have a look at: https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager/issues/226
Here the Corrupt error is caused by a disabled reassembly. In your case the buffer size is set to 384, which looks like the MTU value, nidicating that reassembly could also be disabled. However, as the buffer size is so small, perhaps iOS version of the library tries to send a bigger packet. Logs would help debug the problem.

The error may be thrown from here: github.com/.../smp.c