VSCP Remote firmware upgrade

This page describes the VSCP boot loader/remote firmware upgrade part of the CLASS1.PROTOCOL mechanism. Note that several other low level boot loader mechanisms that are more suited for low memory footprint devices are available. Many devices of today have the capability for in circuit programming and can have their firmware changed whilst still in the system. This is supported by VSCP with boot loader events.

Most flash devices are programmed block by block. The boot loader algorithm must support this. Blocks are usually quite small but to be compatible with future devices 16-bit words are used to describe a block size. 16-bit words are also used to describe the number of available blocks. This means that the total Flash size is described by a 32-bit word and the maximum flash size supported is thus four gigabytes.

The boot loader sequence is as follows:

1. The master instructs the node to enter boot loader mode by sending an CLASS1.PROTOCOL, Type = 12 (0x0C) Enter boot loader mode event to the node. A node whcih needs a firmware upgrade now can use the VSCP boot loader which is described here or another boot loader.
2. The node confirms that it is ready for code loading by sending the CLASS1.PROTOCOL, Type = 13 (0x0D) ACK boot loader mode event (a CLASS1.PROTOCOL, Type = 14 (0x0E) NACK boot loader mode event is also possible). Block size and number of blocks are sent as arguments in the acknowledge message.
3. The master sends a start block data transfer message to specify which block should be programmed and to initiate the transfer of data for the block. Response can be CLASS1.PROTOCOL type=50 (Start block data transfer ACK)/51(Start block data transfer NACK)
4. The master sends one or several block data messages until the complete block is transferred.
5. When all data for a block is received by a node it sends a confirm block event to acknowledge the reception of a complete block.
6. The master now sends a program block event to the node to make it write the block buffer into flash memory.
7. The node confirms the block programming by responding with an ACK program block event.
8. The next block is handled or the node is taken out of the boot loader mode by sending a drop nickname/reset device message.
9. To activate the new firmware code the boot loader sends a CLASS1.PROTOCOL, Type = 22 (0×16) Activate new image event with the 16 bit CRC for the new block as an argument. Response can be CLASS1.PROTOCOL type=48 (Activate new image ACK)/49(Activate new image NACK) If everything is OK the new node should come up after a reboot. The 16-bit CCITT CRC is used as a checksum.

The bootloader is built to direct control flash if other methods such as intermediate storage is used. Data can be loaded direct and program block can just get a dummy ACK.

Platform specific bootloaders are also available. See CLASS1.PROTOCOL, Type = 12 (0x0C) Enter boot loader mode for codes.