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.

[Vidar Berg]

Hello,

Could you please post a video or screenshot of the exact error you’re seeing? This may help us determine if it’s a separate issue or related to the one discussed in your previous ticket. It does seem odd that a 100% identical binary would be seen as valid on one phone but invalid on another.

Best regards,

Vidar

[Phattaw]

Here's the DFU from iOS.

[Vidar Berg]

Thank you. I have forwarded this to our apps team to see if they have  any thoughts on this. Due to some internal activities, I'm not sure if they will be able to respond this week, but if not, I expect to hear back from them on Monday.

[Phattaw]

Has anything happened with this? Also, the app guy said that it didn't work on previous versions. He had fooled himself because of the ping/pong buffers.

[Vidar Berg]

I'm sorry, I forgot to put this ticket back in my queue and to follow up on it. I discussed with one of the ios devs today and he confirmed that the error (MGMT_ERR_ECORRUPT) is raised by the dfu target. This usually means there is something wrong with the binary itself. Are you able to debug your FW to see where the error is returned?

Phattaw said:

He had fooled himself because of the ping/pong buffers.

I'm sorry, but I don't quite understand what you mean. Was he using the same firmware binary the entire time?

[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