I’m building a bootloader and application, both are using UAVCAN v1.0.
The bootloader is capable of updating the application, and the application is capable of updating the bootloader. The bootloader and application firmware images are versioned separately. For example, the bootloader may be at version 1.2, and the application at version 2.3.
I’m looking for advice on how to handle the node id. Should the bootloader use the same node id as the application, but report mode=uavcan_node_Mode_1_0_SOFTWARE_UPDATE in the GetInfo response? Does this seem correct, even though the bootloader will be reporting different version information (major.minor.vcs.crc)? (The spec says “The version information shall not be changed while the node is running.”
Given the language in the spec, would the correct approach be to use a different node id for the bootloader?
This is fine but note that there is no way to report the version info of the bootloader. The uavcan.node.GetInfo response provided by the bootloader shall contain the version info of the currently installed application, or zeros if there is none.
The bootloader may use the same node-ID as the application. This does not contradict the clause you are referring to as long as the uptime counter is reset when the bootloader (or the application) is started.
Also, there is no mode field in the GetInfo response. I think you meant the heartbeat.
Makes sense. I’ll have the bootloader report the application’s version info (if available).
Do you have any advice on how to manage getting the bootloader’s version information, and initiate a firmware update of the bootloader from the application?
I suppose I could add a custom data type that looks like GetInfo, for example, GetBootloaderInfo. And define a custom ExecuteCommand to start the bootloader update.
Yes, that is a valid option. As a more lightweight alternative, perhaps consider defining a new register in the application of type like natural8[2] (major, minor) for the bootloader version.