AT#XDFUGET improvement request

[Gaétan]

I implemented the nRF52840 (auto)upgrade with an nRF9160 on the nRF9160DK.
I did my development with the Serial Modem LTE application from nRF Connect SDK 2.0.0. 
I noticed some lights malfunctions in the documentation and the use of the AT#XDFUGET command.

1. I have made an error in the command formating:

//Be carrefull command WITH ERROR !
AT#DFUGET=1,"http://dev.xxxxx.com/xxxx/mcu", "yyyyy.dat","yyyyy.bin"

Result:

[00:01:10.913,635] <inf> download_client: Connecting to http://dev.xxxxx.com/xxxx/mcu
[00:01:11.202,728] <inf> download_client: Downloading: yyyyy.dat [0]
[00:01:11.904,693] <err> download_client: Unexpected HTTP response: 200 ok
[00:01:11.904,724] <inf> dfu: EVT_ERROR
[00:01:11.905,090] <err> dfu: Download client error

HTTP response = 200 is a good result but -> ​<err> download_client: Unexpected HTTP response: 200 ok

and the SLM application is freezed, need a hard reset for restart...

When AT#XDFUGET is correctly writen, no problem

AT#DFUGET=1,"http://dev.xxxxx.com", "xxxx/mcu/yyyyy.dat","xxxx/mcu/yyyyy.bin"

2. #XDFUGET answers can make somes confusions besause the second parameter is in percent but the last answer is the size of the downloaded .bin file:

#XDFUGET 1, 4
#XDFUGET 1, 7
...
#XDFUGET 1, 97
#XDFUGET 1, 100
#XDFUGET 1, 39804 

[Hakon]

Response from SDK team;

#1 the paramter of Host and Path (<image1>, <image2>) are following https://en.wikipedia.org/wiki/Uniform_Resource_Identifier

The correct HTTP response should be 206 instead of 200 as Range is enabled

The freeze is due to infinite wait of semaphore, which is a mistake 

#2 Yes this is bad design. We'll try to improve

 

Fixed in https://github.com/nrfconnect/sdk-nrf/pull/8169

New #XDFUSIZE to get image size after downloading. No more URC.

Check the AT command spec here.

Also fixed the freeze issue (when Host and Path are not correct).

[Hakon]

PR#8169 is merged into NCS main. Can you verify that it is working now?