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

I just upgraded NCS to 2.8.0 and created a brand new modem delta update example based on 2.8.0. In it, I only modified the server address and file name, and everything else was the default code. I still encounter the same problem in this version

Here is a complete serial port output information

In the figure, it can be seen that when I pressed the button for the first time, 9160 connected to my server and downloaded the first 2k sized segment with an offset of 0, but still prompted me to delete the modem firmware. After the deletion was completed, the download client returned an error and prompted me to press the button again to download. At this moment, I pressed the button for the second time and the output message showed that I was connecting to the server. However, after a few seconds, the LTE network was disconnected. After waiting for a while, the output message showed that 9160 downloaded the first 2k segment from my server again and paused the download. Then, it read an offset of 452 from the DFU and continued to download firmware from the server using this offset. At this point, waiting for the download to complete will result in a successful update

Here is an example of a modem full update based on version 2.8.0. I only need to press the button once to download and update normally, and the offset value is also normal, not 452 or anything else

[llly]

Full update requires pressing two buttons, while delta update uses the same button.

You probably didn't understand what I meant

[dejans]

Hi,

We will investigate this issue. I will get back to you with status update by the end of next week.

Best regards,
Dejan

[llly]

ok thank you

[llly]

hi dejans

Is there any new progress on this issue？

[dejans]

Hi,

The download will be aborted if there is an error on receive and then it has to be restarted. That is expected. If the download is in progress (with an offset returned by modem), fota_download will cancel the current download and start a new one from the given offset. If the offset is actually zero because it has already been erased, it will continue and if the offset is dirty (0x280000) it must be erased first.

It could be that there is a log synchronization issue in your terminal output. It looks like some lines are using logging module while others use printk(). The offset is read in dfu_target_modem_delta_init() and if it is dirty, the area will be erased. Then dfu_target_offset_get() is called in the download_client_callback which will return 0 and then 452 after first write. Can you try to use logging module for all logs (and not mix it with printk())? You could also add logs for all offsets reported by calls to nrf_modem_delta_dfu_offset() in dfu_target_modem_delta.c. This might show different behavior.

Best regards,
Dejan

[llly]

Okay, I'll try using the log module when I have time and get back to you