uavcan.protocol.file.BeginFirmwareUpdate

YGQ · June 24, 2019, 1:05pm

Hello, now my UAVCAN node received this message and implemented a jump to the bootloader. Now how should I handle the firmware upgrade? Is it possible to call uavcan.protocol.file.Read directly, but I think it is There should be no response information, I am not sure how the whole process is, ask for help. Thank you！！

pavel.kirienko · June 24, 2019, 7:46pm

Please read this: https://uavcan.org/Specification/6._Application_level_functions/#firmware-update

Also this: https://uavcan.org/Implementations/Libuavcan/Tutorials/11._Firmware_update/ The tutorial is for libuavcan, not libcanard, but the general principles are the same so you can use it as a high-level reference.

The Kocherga protocol module implements the UAVCAN bootloader protocol: https://github.com/Zubax/kocherga/blob/master/kocherga_uavcan.hpp (and it is built on Libcanard!)

YGQ · June 29, 2019, 6:24am

thank you

YGQ · June 29, 2019, 6:28am

Continuing the discussion from uavcan.protocol.file.BeginFirmwareUpdate:

I have another problem now. When I receive a lot of data, I can’t enter onTransferReceived. For example, when I receive the information of the file, I can’t confirm what the problem is.

pavel.kirienko · June 29, 2019, 1:10pm

You might be losing frames to RX queue overrun. If you’re using STM32, this might be relevant:

github.com/Zubax/kocherga

libcanard polling too slow

opened 02:46PM - 04 May 19 UTC

closed 03:11PM - 04 May 19 UTC

chemicstry

I'm not sure whether this issue belongs to this repository but at least I will s…hare the problem I encountered. I'm using this bootloader on a STM32F103 @ 72 MHz and the main bootloader loop is too slow to poll libcanard stm32 driver receive function hence losing packets during file transfer. The internal receive buffer is only 2 frames and it seems that it cannot keep up with 1mbps CAN bitrate. The way I solved this is by making libcanard driver interrupt driven and feeding frames to an intermediate RX queue (ChibiOS FIFO). This is highly platform specific, but I think someone will definitely encounter this issue. I'm not sure if this should be fixed by making libcanard driver buffered or by other means.

YGQ · July 1, 2019, 3:59am

Yes, it is this problem that has been resolved. I need to send a message to the file service after I get and update, or I can directly convert the state of the UAVCAN node from SOFTWARE_UPDATE to OPERATIONAL.

YGQ · July 4, 2019, 3:01am

How to verify the uavcan protocol file transfer part, I have not found relevant information at present, I feel that the transmission process is prone to errors.

pavel.kirienko · July 30, 2019, 9:09am

The updatee can just switch its published mode to OPERATIONAL, no additional steps are required.

Unrelated: you can’t send a “message” to a service, these are opposite concepts. You can send either a service request or a service response, there is no such thing as “service message”.

Either:

Embed a CRC into your file and check it. This works if the file is a firmware image (you probably need a CRC there anyway regardless of UAVCAN).
Use a separate hash file as described here (the linked definition is for UAVCAN v1 but it is istill applicable to v0):

github.com

UAVCAN/public_regulated_data_types/blob/a532bfa7d09409f1d160bdf5240ebd7430a662ba/uavcan/file/408.Read.1.0.uavcan#L14-L29


# It is easy to see that this protocol is prone to race conditions because the remote file can be modified
# between read operations which might result in the client obtaining a damaged file. To combat this,
# application designers are recommended to adhere to the following convention. Let every file whose integrity
# is of interest have a hash or a digital signature, which is stored in an adjacent file under the same name
# suffixed with the appropriate extension according to the type of hash or digital signature used.
# For example, let there be file "image.bin", integrity of which must be ensured by the client upon downloading.
# Suppose that the file is hashed using SHA-256, so the appropriate file extension for the hash would be
# ".sha256". Following this convention, the hash of "image.bin" would be stored in "image.bin.sha256".
# After downloading the file, the client would read the hash (being small, the hash can be read in a single
# request) and check it against a locally computed value. Some servers may opt to generate such hash files
# automatically as necessary; for example, if such file is requested but it does not exist, the server would
# compute the necessary signature or hash (the type of hash/signature can be deduced from the requested file
# extension) and return it as if the file existed. Obviously, this would be impractical for very large files;
# in that case, hash/signature should be pre-computed and stored in a real file. If this approach is followed,
# implementers are advised to use only SHA-256 for hashing, in order to reduce the number of fielded
# incompatible implementations.

YGQ · August 6, 2019, 5:08am

Thank you for your help, I have implemented the above functions.