This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

LWM2M lifetime registration fails during modem delta erase

I have a product with an nRF9160 and using its modem to connect to a LWM2M server. I have recently enabled modem delta firmware updates, and have seen an annoying issue.

The first thing that is being done by the dfu_modem_delta code is to create a DFU socket and then erase the memory used for the delta update on the modem flash. This erase takes around 10-15 seconds in my case. After the erase is done, The data from the first block is used/written, then next block etc.

The lwm2m_rd_client/lwm2m_engine has a lifetime, used to re-register to the lwm2m server at an interval, to indicate that the client is still alive. What I noticed when doing modem delta update was that if I was unlucky and happened to want to re-register during the erase, the re-register fails, causing the client to lose connection to the server, and thus kind of aborting the modem update, since no more firmware blocks can be received until we have done a complete new registration, and then I have to actually re-initiate the download on the server side. And following downloads don't have to do the erase, but then I get errors from the modem, with type -5, basically indicating that the data is incorrect/corrupted (Maybe because the erase was interrupted? Or because we transfer wrong block of data?)

Is this a known problem? And what is the suggested way to avoid this?

I generally use a lifetime of 30 seconds, which gives around 50 % risk to get the error. I could force a re-register before doing the erase (to make sure I have ~30 seconds to do the erase), but that seems like only a temporary fix, and wouldn't work for shorter lifetimes.

Regards,

Andreas Pettersson

Parents
  • Hi again, follow up question: How come the erase is done on the whole block at once and not one section at a time? That's how it's done for DFU of the nrf9160 application. That would make each erase take shorter time, allowing for better interleaving.

    Regards,

    Andreas Pettersson

  • Hello Andreas, 

    What modem delta FW files are you using to download and update your device? How did you enable modem delta firmware in your application?

    Do you have any log output that can provide more details on this matter? What version of NCS are you running? 

    Kind regards,
    Øyvind

  • Hi,

    Increasing the CONFIG_LWM2M_ENGINE_DEFAULT_LIFETIME would only be effective until the server sets it to some other value. And also, increasing the default lifetime or setting the lifetime from the server will both just decrease the risk of this happening, not remove it.

    Of course, a block by block erase wouldn't remove the risk entirely either, but it would be so unlikely that it shouldn't be a problem in most cases, at least if the CONFIG_LWM2M_SECONDS_TO_UPDATE_EARLY is set to a not too small value. The default of 6 seconds should be fine (if using block by block erase).

    Thanks for forwarding this to the developers.

    Regards,

    Andreas

  • Hello Andreas, 

    The developers inform that they are aware of the erase issue, and that they are currently working on a patch. There isn't much that we can do to reduce the modem erase time. Have you tried calling the keep-alive in its own thread?

     Still waiting for more feedback from our LwM2M expert.

    Kind regards,
    Øyvind

  • Hello,

    OK, thanks, good that they are working on a fix. I am assuming that won't be made available until 1.3.2 at best? And I am guessing it needs updates to the DFU lib as well then?

    Well, the problem is that the modem erase is done when I get the first block of firmware data, because that block is used to decode what type of firmware it is. This thread seems to be the lwm2m_recv thread, not sure exactly of the priorities of that, but it seems to have higher priorities than my user threads. And I cannot delegate the firmware block/modem erase to another user thread/app work task, because when I reply to the lwm2m cb, I could immediately get the next block of data, overwriting the first block before I have had time to handle it (this is when pushing firmware).

    I have firmware HTTP download also set up, and since that is done in a lower priority thread I have been able to do a  workaround, where I temporarily increase the lifetime, and manually force an update, then sleep/yield to make sure the lwm2m thread that handles updates is allowed to update, before I continue with the modem erase and further download. But this is not a pretty fix in my opinion.

    The keep-alive/update is already done in its own thread, but the issue lies in the thread priorities, and the write callback of the firmware taking too long (due to the modem erase).

    Regards,

    Andreas

  • Hi Öyvind,

    Any updates from the LwM2M expert?

    Regards,

    Andreas

  • Hi Andreas, yes, I did get an answer. He doesn't think there's anything to be done on the LwM2M side, apart of the already suggested increasing lifetime. If the modem is busy with erase then nothing can go out during that period.

    The developers are looking into this and might have a fix. No timeline at the moment.

    Kind regards,
    Øyvind

Reply
  • Hi Andreas, yes, I did get an answer. He doesn't think there's anything to be done on the LwM2M side, apart of the already suggested increasing lifetime. If the modem is busy with erase then nothing can go out during that period.

    The developers are looking into this and might have a fix. No timeline at the moment.

    Kind regards,
    Øyvind

Children
Related