9160modem delta update issue

[llly]

My NCS version is 2.6.1, and the modem firmware version is 1.3.6

I found that delta upgrade often fails when testing the firmware of FOTA upgrade modem for 9160. Currently, I have discovered that there are some issues with the dfu_target _offset_get function in the dfu_target header file.

According to the upgrade process, the first step is to use dfu_target_init, which requires passing in a parameter to determine the update type. When I successfully initialize with DFU_TARGET_IMAGE_TYPE_FULL_MODEM, I then use dfu_target _offset_get to read the flash area in the modem used to store the update firmware. Generally, a normal result is obtained, which is 0. Then, I continue to use dfu_target_write to loop through the modem and write the new firmware. I choose to write 2k each time. When I write 2 times, that is, every 4k data is written, and then use dfu_target_write again, I will get a 4096 offset until the firmware is completely written. Successfully updated.

The problem occurs in delta updates.I initialize the dfu target using DFU_TARGET_IMAGE_TYPE_MODEM_DELTA, and then use dfu_target_offset_get to read an offset of 452, which may not be the same. Based on my testing, this is related to the selected delta firmware, sometimes it is 580 or other values.

However, ignoring this impact, we continued to use dfu_target_write to write delta firmware to the modem at a size of 2k each time, and eventually the update was successful. But during this period, when I write 4k and read the offset again, I still got 452 or the value before writing. It wasn't until I wrote a total of 8k that I got the offset of 8644, which is 8k plus 452. That is to say, after delta upgrade initialization, the minimum unit of dfu_target_offset_get is 8k, while using full upgrade initialization has a minimum unit of 4k.

Why do the values obtained by using dfu_target_offset_get in two different update methods differ? This caused problems with the routine I tested as well.

In the routine of upgrading modem firmware in FOTA, the full update is normal, but the delta update may encounter the problem shown in the screenshot below

After downloading 2k data, automatically start clearing the area in the modem where firmware updates are stored. I analyzed it and the problem lies in the download_cient_callback of fota-d ownload. c.According to the process in this function, after initializing the dfu target, it is determined whether the last update was interrupted by reading the offset. However, due to the issue I mentioned earlier, dfu_target_offset_get always reads a value other than 0, which leads to entering another step instead of downloading and updating normally. In full updates, the offset value is normally 0, so it can be updated smoothly

[dejans]

Hi,

Why do the values obtained by using dfu_target_offset_get in two different update methods differ?

The offset should only be used when the application begins the DFU process. If the offset is non-zero the application can resume from that offset. If it is zero the application begins from scratch. The values of offset during the DFU process are opaque to the application. The application does not need to inspect offset value or care about it during the DFU process. 

Best regards,
Dejan

[llly]

hi

In the download_with_offset of fota_download. c, dfu_target_offset_get is also used to read the offset to continue updating from the last interrupted position, instead of starting from scratch?

In addition, in the delta update, the offset is also read at the beginning of the dfu. The read offset should have been 0, but it was read as a different value. Therefore, in download_client_callback, it is considered that the last update was not completed, but in fact, there was no previous update, which caused an error to enter the process shown in the figure below. Can you help me try to see if this problem can be reproduced？