9160modem delta update issue

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

Parents Reply Children
  • 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

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

Related