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

FOTA in nRF91 SLM gets 404 due to double `/` in file path

I am unable to do a FOTA with the SLM application on a nRF9160. When I try to do a FOTA with the command below, I get a 404 even though I know the URL exists (real host name redacted). For reference, this is on NCS v1.9.1.

AT#XFOTA=1,"http://our.website.com/app_update.bin"

After digging a bit more, I realized that the http_parser_url lib used from Zephyr is returning the file path including the prefixed /. However, it looks like the Nordic download_client library is also adding an implicit / at the beginning of HTTP GET requests. I confirmed that the HTTP GET request was indeed sending up the path //app_update.bin with some added debug logging statements which explains the 404 I was seeing. See: https://github.com/nrfconnect/sdk-nrf/blob/v1.9.1/subsys/net/lib/download_client/src/http.c#L21. As far as I can tell, my usage of the XFOTA AT command follows the examples in the docs here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/FOTA_AT_commands.html#example

I was able to do a FOTA update by modifying the download_client's GET templates to remove the extra leading /, but this doesn't feel quite right to me, nor a good production solution. I hope I'm missing something simple.

Could I get some input on if I am doing something wrong on my end, and if not if there is a bug here and what a possible fix is?

Thanks!

Parents Reply Children
  • Thank you Charlie, that's great news. I have a follow on question, does this mean that FOTA update was completely broken in v1.9.1 for the SLM? If so, I'm curious on the details of how that bug slipped in to a production release. We intend to use the SLM in production, and breakage of a critical feature like FOTA update in an SDK release needs some understanding from our side.

  • Hi Matt,

    Not sure by far, in fact, I set up an HTTP server yesterday in order to do the test by myself. I can confirm the problem exists and your solution works on my side now, but I still need to have further discussion with the developers in Japan which has Golden Week vacation time now. They will be back next week. I have raised an internal case to follow up on this issue and will give you an update on your concern. 

    This ticket will keep open until we figure out the cause. Thank you again for your patience.

    Best regards,

    Charlie 

Related