UAVCAN Firmware Update Questions
85 views
Skip to first unread message
OlliW
Mar 29, 2018, 8:13:29 AM3/29/18
to UAVCAN
Hey Pavel
I'm trying to implement a UAVCAN bootloader and think I have the skeleton working, but some things are strange with the UAVCAN GUI Tool and I don't understand what it is doing, or what I need to do to make it happy.
I'd like to mention that my node outputs debug info on an uart, which means that I can see quite accurately what is actually going on, i.e., everything I say in the below I can see to actually happen.
Questions/issues:
1) When I start "Update Firmware", I can see that my node sends out a response to the file.BeginFirmwareUpdate requset with error = 0, the bootloader starts, the mode goes into mode Software_Update, and with file.Read requests and receives the complete data of the file, of correct length, and with all errors = 0.
However: This happens twice, and in the GUI Tool I do see - while the update is ongoing - plenty of messages related to file.BeginFirmwareUpdate, which includes "One of the firmware update requests have timed out", or "Firmware update response: ..." with errors 1 or 255.
It appears that the GUI Tool is continuing to send out file.BeginFirmwareUpdate, even though the update has already started. i.e., the mode is Software_Update and the GUI has received file.Read requests. I have noted that the GUI tries initiating an update up to 4 times, but I would have thought that it would stop this once it got a positive response.
What is going on here?
What does one have to do to satisfy the GUI Tool?
The specs read as if only one positive response to a file.BeginFirmwareUpdate is required.
2) There can be two situations, either there is a valid application which should be updated or there is not. As much as I understand, in the first case the node should go into mode Software_Update and immediately start with requesting file.Read. However, in the second case I would want the node to go into a regular loop and wait for a file.BeginFirmwareUpdate, and only when start the update process. Into which mode should the mode be during this period? Initialization? Maintenance?
Thx!
Cheers, Olli
I'm trying to implement a UAVCAN bootloader and think I have the skeleton working, but some things are strange with the UAVCAN GUI Tool and I don't understand what it is doing, or what I need to do to make it happy.
I'd like to mention that my node outputs debug info on an uart, which means that I can see quite accurately what is actually going on, i.e., everything I say in the below I can see to actually happen.
Questions/issues:
1) When I start "Update Firmware", I can see that my node sends out a response to the file.BeginFirmwareUpdate requset with error = 0, the bootloader starts, the mode goes into mode Software_Update, and with file.Read requests and receives the complete data of the file, of correct length, and with all errors = 0.
However: This happens twice, and in the GUI Tool I do see - while the update is ongoing - plenty of messages related to file.BeginFirmwareUpdate, which includes "One of the firmware update requests have timed out", or "Firmware update response: ..." with errors 1 or 255.
It appears that the GUI Tool is continuing to send out file.BeginFirmwareUpdate, even though the update has already started. i.e., the mode is Software_Update and the GUI has received file.Read requests. I have noted that the GUI tries initiating an update up to 4 times, but I would have thought that it would stop this once it got a positive response.
What is going on here?
What does one have to do to satisfy the GUI Tool?
The specs read as if only one positive response to a file.BeginFirmwareUpdate is required.
2) There can be two situations, either there is a valid application which should be updated or there is not. As much as I understand, in the first case the node should go into mode Software_Update and immediately start with requesting file.Read. However, in the second case I would want the node to go into a regular loop and wait for a file.BeginFirmwareUpdate, and only when start the update process. Into which mode should the mode be during this period? Initialization? Maintenance?
Thx!
Cheers, Olli
Pavel Kirienko
Mar 29, 2018, 4:29:35 PM3/29/18
to OlliW, UAVCAN
Hey Olli,
1. Your bootloader is fine. The GUI tool has to emit multiple requests in a row because there is one particular bootloader implementation that is not up to spec - this is the PX4 Brickproof Bootloader: https://github.com/PX4/UAVCAN_Bootloaders. The problem with it is that when the application receives a BeginFirmwareUpdate request, it launches the bootloader, but currently it has no way to pass the required metadata to the bootloader, so it can't begin the update process until it receives another BeginFirmwareUpdate request. Someday somebody should fix it.
2. Maintenance. There are a lot of outstanding issues with the specification which I should fix soon; I just need to dedicate at least a week of my time to get to that.
Pavel.
--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/6931117c-ed26-4f16-8e35-f9bbd61cad92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
OlliW
Mar 30, 2018, 4:49:28 AM3/30/18
to UAVCAN
Hey Pavel
many thx for the clarification, very useful to know about what and why the GUI Toll is doing what it does.
Just for reference, in case anyone passes by: I got the "best results" by making the bootloader to respond with error = 2 to BeginFirmwareUpdate request.
many thx for the clarification, very useful to know about what and why the GUI Toll is doing what it does.
Just for reference, in case anyone passes by: I got the "best results" by making the bootloader to respond with error = 2 to BeginFirmwareUpdate request.
the application receives a BeginFirmwareUpdate request, it launches the bootloader, but currently it has no way to pass the required metadata to the
bootloader, so it can't begin the update process until it receives another BeginFirmwareUpdate request.
yeah, I encountered that problem too, how to exchange all the data, it was the part which took me the longest to find a work-around :)
I wonder now though, if I shouldn't also follow what the PX4 brickproof bootloader is doing. This would make the bootloader considerably simpler. I would think that "all" bootloaders suffer from a similar problem, and maybe the protocol could be changed to account better for that.
Maintenance is fine. Maybe an additional mode "InBootloader" or similar might be useful in a future improvement.
Maybe another question:
With using Maintenance it's possible for the user to see that the node is in the bootloader, but I'd like to give a bit more info. For instance I wonder if it would be OK to tweak the name and versions, such as to indicate that it's the bootloader and give the version of the bootloader. What do you say: Ok or not OK to do such tweaks?
Thx,
Olli
I wonder now though, if I shouldn't also follow what the PX4 brickproof bootloader is doing. This would make the bootloader considerably simpler. I would think that "all" bootloaders suffer from a similar problem, and maybe the protocol could be changed to account better for that.
Maintenance is fine. Maybe an additional mode "InBootloader" or similar might be useful in a future improvement.
Maybe another question:
With using Maintenance it's possible for the user to see that the node is in the bootloader, but I'd like to give a bit more info. For instance I wonder if it would be OK to tweak the name and versions, such as to indicate that it's the bootloader and give the version of the bootloader. What do you say: Ok or not OK to do such tweaks?
Thx,
Olli
Jonathan Challinger
Mar 30, 2018, 4:45:07 PM3/30/18
to OlliW, UAVCAN
Maybe you have an old gui tool version? IIRC I fixed this issue in this PR: https://github.com/UAVCAN/gui_tool/pull/17
--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/389448e2-a8e5-4944-bd50-a6f80a87a171%40googlegroups.com.
OlliW
Mar 30, 2018, 5:31:56 PM3/30/18
to UAVCAN
ah, interesting, THX
I do have version v0.9.0, which is the latest for which there is a .msi for Windows ... from here https://files.zubax.com/products/org.uavcan.gui_tool/ it however appears that this version is from 2017-04-05 ... so, I guess, you're right ... that's sad :)
(I once tried running the python code, without success, even though I use PyQT myself, so I'm stuck with the .msi ;))
it works quite well and reliably by now, however
I do have version v0.9.0, which is the latest for which there is a .msi for Windows ... from here https://files.zubax.com/products/org.uavcan.gui_tool/ it however appears that this version is from 2017-04-05 ... so, I guess, you're right ... that's sad :)
(I once tried running the python code, without success, even though I use PyQT myself, so I'm stuck with the .msi ;))
it works quite well and reliably by now, however
Pavel Kirienko
Mar 31, 2018, 2:13:41 PM3/31/18
to OlliW, UAVCAN
Olli,
> For instance I wonder if it would be OK to tweak the name and versions, such as to indicate that it's the bootloader and give the version of the bootloader. What do you say: Ok or not OK to do such tweaks?
Not OK. Although the following is not explicitly stated in the specification yet, it becomes more or less obvious after some pondering: the reported name and version information can be relied upon by external nodes (e.g. autopilot) to decide whether or not a particular node should be updated. In order to support this use case, the bootloader should report the actual version information and name of the application (firmware) that is installed on the device (if any). This is going to be a hard requirement in the future.
That said, the protocol might benefit from additional information allowing external nodes to determine whether it's the application that is running or the bootloader. We have a lot of flexibility with operating modes here. For instance, one could explore using the mode SOFTWARE_UPDATE with a non-OK status code for that, to indicate that the bootloader is running but no firmware update process is currently in progress due to lack of data.
Pavel.
--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/38182380-d42c-42c1-a648-a54974b76dce%40googlegroups.com.
OlliW
Apr 1, 2018, 2:59:53 AM4/1/18
to UAVCAN
Hey Pavel
thx for the answer
I'm not so sure if it is so obviously wrong to change the name. The unique relevant information for proper operation only can be the node id, nothing else. GetNodeInfo is formally not even required. And the name really should not be used by an autopilot to decide what action it wants to do or not.
IMHO there is clearly a need to provide much more and better information and possibilities, which the available mechanisms currently just don't provide. For instance, I think it is a crucial information to know the version of the bootloader. And the bootloader can't really be considered part of the application. Currently there is not even a defined procedure to tell a user if an update was successful or not, she/he only can tell by looking at some fine details. So, I fully agree, that once there is a usable and fletched out update mechanism available, bootloaders should adhere to that ... but, honestly, that's far future. However, things are needed now ;). I mean, you yourself described the PX4 bootloader situation.
Anyway, I currently change the name (and version) while in the bootloader, and find it SUPER convenient (but that's nothing UAVCAN bothers with, right).
I do realize that it was really stupid of me to ask this particular question at all, sometimes my learning curve is too shallow. :)
Thx, Olli
thx for the answer
I'm not so sure if it is so obviously wrong to change the name. The unique relevant information for proper operation only can be the node id, nothing else. GetNodeInfo is formally not even required. And the name really should not be used by an autopilot to decide what action it wants to do or not.
IMHO there is clearly a need to provide much more and better information and possibilities, which the available mechanisms currently just don't provide. For instance, I think it is a crucial information to know the version of the bootloader. And the bootloader can't really be considered part of the application. Currently there is not even a defined procedure to tell a user if an update was successful or not, she/he only can tell by looking at some fine details. So, I fully agree, that once there is a usable and fletched out update mechanism available, bootloaders should adhere to that ... but, honestly, that's far future. However, things are needed now ;). I mean, you yourself described the PX4 bootloader situation.
Anyway, I currently change the name (and version) while in the bootloader, and find it SUPER convenient (but that's nothing UAVCAN bothers with, right).
I do realize that it was really stupid of me to ask this particular question at all, sometimes my learning curve is too shallow. :)
Thx, Olli
Jonathan Challinger
Apr 1, 2018, 6:41:21 PM4/1/18
to OlliW, UAVCAN
Could build the bootloader version into the hardware version.
--
You received this message because you are subscribed to the Google Groups "UAVCAN" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavcan+unsubscribe@googlegroups.com.
To post to this group, send email to uav...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uavcan/b36de45f-aadc-4eaa-84d2-7dd72ad3314b%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages