Sample LWM2M client using for FOTA

[Remo94]

Hi

So I tried to use the lwm2m sample client (nrf\samples\nrf9160\lwm2m_client) for FOTA upgrades. I do get a connection to my plattform. When I start the update I do get the following in a loop.

m[8D[J[1;32muart:~$ [m[8D[J[00:00:50.592,498] [1;31m<err> net_lwm2m_engine: Unknown IP address family:0
[0m[1;32muart:~$ [m[8D[J[00:00:50.592,529] [0m<dbg> net_lwm2m_engine.lwm2m_udp_receive: checking for reply from [unk]
[0m[1;32muart:~$ [m[8D[J[00:00:50.592,590] [0m<dbg> net_lwm2m_engine.handle_request: No accept option given. Assume OMA TLV.
[0m[1;32muart:~$ [m[8D[J[00:00:50.592,681] [0m<dbg> net_lwm2m_engine.engine_add_observer: OBSERVER DUPLICATE 5/0/3(3) []
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,600] [1;31m<err> net_lwm2m_engine: Unknown IP address family:0
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,630] [0m<dbg> net_lwm2m_engine.lwm2m_udp_receive: checking for reply from [unk]
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,661] [0m<dbg> net_lwm2m_engine.handle_request: No accept option given. Assume OMA TLV.
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,752] [0m<dbg> net_lwm2m_obj_firmware.package_uri_write_cb: PACKAGE_URI WRITE: 
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,783] [0m<dbg> net_lwm2m_engine.lwm2m_notify_observer: NOTIFY EVENT 5/0/3
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,783] [0m<dbg> net_lwm2m_obj_firmware.lwm2m_firmware_set_update_state: Update state = 0
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,813] [0m<dbg> net_lwm2m_obj_firmware.lwm2m_firmware_set_update_result: Update result = 0
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,875] [0m<dbg> net_lwm2m_engine.lwm2m_notify_observer: NOTIFY EVENT 5/0/3
[0m[1;32muart:~$ [m[8D[J[00:00:50.921,875] [0m<dbg> net_lwm2m_obj_firmware.lwm2m_firmware_set_update_state: Update state = 1
[0m[1;32muart:~$ [m[8D[J[00:00:50.922,027] [0m<dbg> net_lwm2m_engine.lwm2m_parse_peerinfo: Parse url: 
[0m[1;32muart:~$ [m[8D[J[00:00:50.922,973] [0m<inf> net_lwm2m_obj_firmware_pull: Connecting to server 
[0m[1;32muart:~$ [m[8D[J[1;32muart:~$ [m[8D[J[1;32muart:~$ [m[8D[J[00:00:51.517,486] [1;31m<err> net_lwm2m_engine: Unknown IP address family:0
[0m[1;32muart:~$ [m[8D[J[00:00:51.517,517] [0m<dbg> net_lwm2m_engine.lwm2m_udp_receive: checking for reply from [unk]
[0m[1;32muart:~$ [m[8D[J[00:00:51.517,578] [0m<dbg> net_lwm2m_engine.handle_request: No accept option given. Assume OMA TLV.
[0m[1;32muart:~$ [m[8D[J[00:00:51.570,526] [0m<dbg> net_lwm2m_engine.generate_notify_message: [MANUAL] NOTIFY MSG START: 5/0/3(3) token:'' [] ERR
[0m[1;32muart:~$ [m[8D[J[00:00:51.571,746] [0m<dbg> net_lwm2m_engine.generate_notify_message: NOTIFY MSG: SENT
[0m[1;32muart:~$ [m[8D[J[00:00:51.637,817] [1;31m<err> net_lwm2m_engine: Unknown IP address family:0
[0m[1;32muart:~$ [m[8D[J[00:00:51.637,817] [0m<dbg> net_lwm2m_engine.lwm2m_udp_receive: checking for reply from [unk]
[0m[1;32muart:~$ [m[8D[J[00:00:51.766,448] [1;31m<err> net_lwm2m_engine: Unknown IP address family:0
[0m[1;32muart:~$ [m[8D[J[00:00:51.766,479] [0m<dbg> net_lwm2m_engine.lwm2m_udp_receive: checking for reply from [unk]
[0m[1;32muart:~$ [m[8D[J[00:00:51.766,510] [0m<dbg> net_lwm2m_engine.notify_message_reply_cb: NOTIFY ACK type:2 code:2.4 reply_token:''
[0m[1;32muart:~$ [m[8D[J[00:00:51.766,601] [0m<dbg> net_lwm2m_engine.lwm2m_udp_receive: reply 0x20021b70 handled and removed[0m

Is the sample client made for FOTA? If not what is needed to upgrade the client to get it working? Is there anywhere a tutorial or something that will help me? 

Kind regards.

[Didrik Rokhaug]

Hi. and sorry for the late reply.

Yes, the lwm2m_client sample should support FOTA.

From your logs, it looks like the server is checking if the device is available for FOTA, which it is.

The server then instructs the device to start the FOTA process, but it does not provide a URL to download the DFU image from.

Best regards,

Didrik

[Remo94]

Hi 

Thanks for your answer! I do now get the URI on my client. But I do get the following:

[00:00:44.699,951] <inf> net_lwm2m_obj_firmware_pull: Connecting to server coap://.........
[00:00:44.942,108] <err> net_lwm2m_obj_firmware_pull: Unexpected response from server: 4.0

For info I did not paste the full URI but it is there. Do you know this error? 

Kind regards. 

[Remo94]

So ok now I am able to download the file. Now I get the following: 

[00:22:07.848,144] <dbg> net_lwm2m_obj_firmware.lwm2m_firmware_set_update_state: Update state = 3
[00:22:07.848,175] <dbg> app_lwm2m_firmware.firmware_update_cb: Executing firmware update
[00:22:07.848,175] <inf> app_lwm2m_firmware: Update Counter: current 0, update 1
[00:22:07.848,724] <inf> app_lwm2m_firmware: Rebooting device
*** Booting Zephyr OS build v2.1.99-ncs1-1145-g13dc96f83bab  ***
[00:00:00.006,958] <inf> mcuboot: Starting bootloader
[00:00:00.015,502] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.028,961] <inf> mcuboot: Boot source: none
[00:00:00.036,285] <inf> mcuboot: Swap type: test
[00:00:10.380,615] <err> mcuboot: Image in the secondary slot is not valid!
[00:00:10.734,100] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:10.741,729] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.1.99-ncs1-1145-g13dc96f83bab  ***

After reboot it states that the firmware update is failed. What can I do to get my app_update.bin valid? 

[Didrik Rokhaug]

It might be that the new version uses a different flash partitioning than the bootloader.

Is the <build folder>/pm.config files the same in both the application that is flashed on the device and the application/version you try to upgrade to?

[Remo94]

Sorry for my late answer. 

So I guess I am doing something wrong. I found the pm.config file in my build folder. But I have no pm.config file of my application. I take the app_update.bin file from the same build folder upload it on the lwm2m server and start the update. Do I have to do anything else?

Edit: I do also not find any signal of version in my pm.config file.

PM_MCUBOOT_ADDRESS=0x0
PM_MCUBOOT_SIZE=0xc000
PM_MCUBOOT_NAME=mcuboot
PM_MCUBOOT_ID=0
PM_0_LABEL=MCUBOOT
PM_EMPTY_0_ADDRESS=0xc000
PM_EMPTY_0_SIZE=0x4000
PM_EMPTY_0_NAME=EMPTY_0
PM_MCUBOOT_PAD_ADDRESS=0x10000
PM_MCUBOOT_PAD_SIZE=0x200
PM_MCUBOOT_PAD_NAME=mcuboot_pad
PM_MCUBOOT_PAD_ID=1
PM_1_LABEL=MCUBOOT_PAD
PM_MCUBOOT_PRIMARY_ADDRESS=0x10000
PM_MCUBOOT_PRIMARY_SIZE=0x77000
PM_MCUBOOT_PRIMARY_NAME=mcuboot_primary
PM_MCUBOOT_PRIMARY_ID=2
PM_2_LABEL=MCUBOOT_PRIMARY
PM_MCUBOOT_PRIMARY_SPAN="spm app mcuboot_pad"
PM_MCUBOOT_PRIMARY_APP_ADDRESS=0x10200
PM_MCUBOOT_PRIMARY_APP_SIZE=0x76e00
PM_MCUBOOT_PRIMARY_APP_NAME=mcuboot_primary_app
PM_MCUBOOT_PRIMARY_APP_ID=3
PM_3_LABEL=MCUBOOT_PRIMARY_APP
PM_MCUBOOT_PRIMARY_APP_SPAN="app spm"
PM_SPM_ADDRESS=0x10200
PM_SPM_SIZE=0xc000
PM_SPM_NAME=spm
PM_SPM_ID=4
PM_4_LABEL=SPM
PM_APP_ADDRESS=0x1c200
PM_APP_SIZE=0x6ae00
PM_APP_NAME=app
PM_APP_ID=5
PM_5_LABEL=APP
PM_MCUBOOT_SECONDARY_ADDRESS=0x87000
PM_MCUBOOT_SECONDARY_SIZE=0x77000
PM_MCUBOOT_SECONDARY_NAME=mcuboot_secondary
PM_MCUBOOT_SECONDARY_ID=6
PM_6_LABEL=MCUBOOT_SECONDARY
PM_SETTINGS_STORAGE_ADDRESS=0xfe000
PM_SETTINGS_STORAGE_SIZE=0x2000
PM_SETTINGS_STORAGE_NAME=settings_storage
PM_SETTINGS_STORAGE_ID=7
PM_7_LABEL=SETTINGS_STORAGE
PM_OTP_ADDRESS=0xff8108
PM_OTP_SIZE=0x2f4
PM_OTP_NAME=otp
PM_NUM=8
PM_ALL_BY_SIZE="mcuboot_pad otp settings_storage EMPTY_0 mcuboot spm app mcuboot_primary_app mcuboot_secondary mcuboot_primary"

[Didrik Rokhaug]

To clarify what I meant in my previous post:

When building your project, a script is run, which places all the images into the flash at fitting places. The bootloader is then given this map of the flash and uses that map to know where to jump to.

Likewise, the application uses the partition map to know where to store update images, and where to write to the bootloader that the image is ok.

Therefore, it is important that the image you update has the same partition map as the image you upgrade from and the bootloader. However, as the partition map is generated for each build, there might be changes between two versions. It is therefore important to extract the partition map from the build that is flashed on the device so that the same map can be used in later builds.

That can be done by copying the partitions.yml (I wrote the wrong filename last time, my apologies) into the project folder, and renaming it to pm_static.yml.

 

Remo94 said:

I take the app_update.bin file from the same build folder upload it on the lwm2m server and start the update.

 If I understand you correctly, you build the sample once, then flash it to the device, and start a FOTA update to the same image?

Then all I mentioned above does not matter. Sorry for the confusion.

---

To check if the problem is with the image or the FOTA process, could you do the following test:

1. Flash the program as normal.

2. In a command line, navigate to the build folder, then run the following commands:

cd zephyr
nrfjprog --program app_moved_test_update.hex

That will write the update image to the secondary_image slot in flash.

3. Reset the device.

You should then see MCUBoot trying to update the firmware, similar to how it looked when you did it over LwM2M.

[Remo94]

Didrik Rokhaug said:

 If I understand you correctly, you build the sample once, then flash it to the device, and start a FOTA update to the same image?

Exactly.

I did these steps. And here is the result. No error but I also do not see any success. So did this work?

*** Booting Zephyr OS build v2.1.99-ncs1-1145-g13dc96f83bab  ***
[00:00:00.007,049] <inf> mcuboot: Starting bootloader
[00:00:00.015,594] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x1
[00:00:00.029,052] <inf> mcuboot: Boot source: none
[00:00:00.036,346] <inf> mcuboot: Swap type: test
[00:00:26.349,334] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:26.356,964] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.1.99-ncs1-1145-g13dc96f83bab  ***

[Didrik Rokhaug]

Remo94 said:

I did these steps. And here is the result. No error but I also do not see any success. So did this work?

 Yes, it does indeed look like it worked. As you are "upgrading" to the same application, we do not expect any change in behavior. But the fact that the bootloader spent some time (presumably swapping the images), followed by a successful boot of the application tells us that the upgrade was successful.

That means that the image itself is OK and that MCUBoot is able to perform an upgrade if there is a valid image in the secondary slot.

The question then becomes: Why are you not able to upgrade to the image when you download it?

Could you send me your app_update.bin?

In addition, I would like you to read out the flash of your device after the image has been downloaded (but preferably before mcuboot tries to boot it). You can read out the flash using nrfjprog:

nrfjprog --readcode readout.hex

Finally, I would also like to see the partitions.yml file from the build you used when you read out the flash.