# Node id for bootloader

**URL:** <https://forum.opencyphal.org/t/node-id-for-bootloader/1496>\
**Category:** Applications & Usage\
**Created:** [October 21, 2021, 9:15pm UTC](https://forum.opencyphal.org/t/node-id-for-bootloader/1496 "2021-10-21T21:15:40Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![slilly\_br](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/slilly_br/32/1008_2.png) [@slilly\_br](https://forum.opencyphal.org/u/slilly_br)\
**Post date:** [October 21, 2021, 9:15pm UTC](https://forum.opencyphal.org/t/node-id-for-bootloader/1496/1 "2021-10-21T21:15:40Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [October 21, 2021, 10:07pm UTC](https://forum.opencyphal.org/t/node-id-for-bootloader/1496/2 "2021-10-21T22:07:57Z")

</div>

> [@slilly\_br](#):
>
> For example, the bootloader may be at version 1.2, and the application at version 2.3.

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.

> [@slilly\_br](#):
>
> 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.”

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.

---

<div class="post-metadata">

**Author:** ![slilly\_br](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/slilly_br/32/1008_2.png) [@slilly\_br](https://forum.opencyphal.org/u/slilly_br)\
**Post date:** [October 21, 2021, 11:09pm UTC](https://forum.opencyphal.org/t/node-id-for-bootloader/1496/3 "2021-10-21T23:09:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [October 22, 2021, 12:28pm UTC](https://forum.opencyphal.org/t/node-id-for-bootloader/1496/4 "2021-10-22T12:28:43Z")

</div>

> [@slilly\_br](#):
>
> 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.