Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Detect first block in LWM2M firmware updates. #16122

Closed
sunkyl opened this issue May 13, 2019 · 3 comments · Fixed by #24053
Closed

Detect first block in LWM2M firmware updates. #16122

sunkyl opened this issue May 13, 2019 · 3 comments · Fixed by #24053
Assignees
@mike-scott
Labels
area: LWM2M area: Networking Enhancement Changes/Updates/Additions to existing features
Milestone
v2.3.0

Comments

@sunkyl
Copy link

sunkyl commented May 13, 2019

Problem
Currently, there is no way to detect when to reset the context of a firmware update via LWM2M when the process is interrupted outside of the block received callback (say in the case of a timeout).

Solution
Some indication of a first block for the callback, or exposing more functions within the LWM2M library that allows for writing our own callbacks that can start the transfer.

Alternatives
Currently, there is the extern function inside the subsystem LWM2M files lwm2m_firmware_start_transfer() that I can use. I can create a semi-functional imitation of the sample post-write callback for the package URI that resets a variable to indicate a context reset, but it also has no access to the functions to change the update state.

Thanks.
@sunkyl sunkyl added the Feature Request A request for a new feature label May 13, 2019
@mike-scott
Copy link
Contributor

@sunkyl Did you want to submit your changes as a PR so we can discuss there while looking at code?

@yaomon
Copy link
Contributor

yaomon commented May 24, 2019

Sorry, switching accounts here.
#16369
I think this is the simplest way. I had briefly considered hijacking the instance id parameter in the write callback to pass 1/0 based on whether the current block size is 0 (indicating the first block) but that is very inelegant.
Given access to the block context, I can check whether the current size is <= coap block size to check for the first block and reset the flash context accordingly.

Thanks.

@mike-scott mike-scott added this to the v2.1.0 milestone Sep 4, 2019
@dleach02 dleach02 modified the milestones: v2.1.0, v2.2.0 Dec 10, 2019
@jhedberg jhedberg modified the milestones: v2.2.0, v2.3.0 Mar 10, 2020
@carlescufi
Copy link
Member

@yaomon could you please submit a new PR?
cc @rlubos

@carlescufi carlescufi added Enhancement Changes/Updates/Additions to existing features and removed Feature Request A request for a new feature labels Mar 24, 2020
@yaomon yaomon mentioned this issue Apr 3, 2020
Merged
carlescufi pushed a commit that referenced this issue Apr 9, 2020
@yaomon @carlescufi
net: lwm2m: Publicize firmware block context
a9b9264 
This change is to allow access to the firmware block context in order to
give the firmware update callback implementation an indication of when
to reset the flash context. Additionally, it allows for a validity check
between the total expected size downloaded and the actual size
downloaded. A simple implementation can check if the block context's
current downloaded blocks is equal to the expected block size in order
to determine if the flash context needs to be reset. This approach
seemed the simplest, and knowing the firmware block context can have
other purposes. This has been tested by accessing the block context
during the update in the block received callback and confirming that the
callback had information regarding the current downloaded bytes.

Fixes #16122

Signed-off-by: Kyle Sun <yaomon18@yahoo.com>
avisconti pushed a commit to avisconti/zephyr that referenced this issue Apr 15, 2020
@yaomon @avisconti
net: lwm2m: Publicize firmware block context
86b37b0 
This change is to allow access to the firmware block context in order to
give the firmware update callback implementation an indication of when
to reset the flash context. Additionally, it allows for a validity check
between the total expected size downloaded and the actual size
downloaded. A simple implementation can check if the block context's
current downloaded blocks is equal to the expected block size in order
to determine if the flash context needs to be reset. This approach
seemed the simplest, and knowing the firmware block context can have
other purposes. This has been tested by accessing the block context
during the update in the block received callback and confirming that the
callback had information regarding the current downloaded bytes.

Fixes zephyrproject-rtos#16122

Signed-off-by: Kyle Sun <yaomon18@yahoo.com>
hakehuang pushed a commit to hakehuang/zephyr that referenced this issue Jun 20, 2020
@yaomon @hakehuang
net: lwm2m: Publicize firmware block context
9c5f344 
This change is to allow access to the firmware block context in order to
give the firmware update callback implementation an indication of when
to reset the flash context. Additionally, it allows for a validity check
between the total expected size downloaded and the actual size
downloaded. A simple implementation can check if the block context's
current downloaded blocks is equal to the expected block size in order
to determine if the flash context needs to be reset. This approach
seemed the simplest, and knowing the firmware block context can have
other purposes. This has been tested by accessing the block context
during the update in the block received callback and confirming that the
callback had information regarding the current downloaded bytes.

Fixes zephyrproject-rtos#16122

Signed-off-by: Kyle Sun <yaomon18@yahoo.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mike-scott mike-scott

Labels
area: LWM2M area: Networking Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Milestone
v2.3.0
Development

Successfully merging a pull request may close this issue.

net: lwm2m: Publicize firmware block context
6 participants
@jhedberg @mike-scott @carlescufi @yaomon @dleach02 @sunkyl