CAN Boot-Loader and Downloader Specification

The latest modifications are underlined.

• Introduction
• Ascendant Station Download Process
• Descendant Station Boot-Loader Process
• Descendant Station Download Process
• Descendant Station Executive Format

Introduction

Until future processors integrate on-chip both a CAN interface and a ROM-ed bootloader, we have to design a CAN boot-loader and to store it in non-volatile EPROM or FLASH memory, but we are free to design our own simple and efficient CAN boot-loader.

As all the code to download comes from a single processor, code download is a sequential, fully deterministic process, therefore no hardware addressing is required, and the CAN identifier bits of every frame may be allocated to data; CAN2.0A 11 bits identifiers (resp. CAN2.0B 29 bits identifiers) may be used to store 1 byte (resp. 2 or even 3 bytes), i.e. a 12.5% (resp. 25% or even 37.5%) increase of download bandwidth.

Every CAN station may program its acceptance masks to accept every frame, whatever its identifier field contents. However, each CAN station must know which rank it has in the download order. This rank may not be stored together with the resident boot-loader, because the download order is decided at compile time, and encoded in the executives (in the macros loadFrom_ and loadDnto_). Therefore, each CAN station must be identified by a Station IDentifier (SID), stored together with its resident boot-loader, which uses it to determine which executive sent by the ascendant CAN station must be downloaded into the local program memory.

ERRATUM: Identifier bits may be ignored and used for data transfer only in the case where every CAN station is programmable, and under the control of a custom bootloader of our own. In the case where at least one CAN station is non programmable, and under the control of a firmware which relies on "classical" CAN addressing (i.e. the frame identifier bits) to accept "command" frames and to reply "status" frames, identifier bits may not be ignored and used for data transfer because they must be used for CAN addressing. In the following, the latter case is assumed, therefore every programmable CAN station programs its acceptance masks to accept only one (and the same) CAN identifier, which is ignored by all non programmable CAN stations.

Root Ascendant Station Download Process

The download process (code generated by the loadDnto_ macro) is the following for the ascendant CAN station:

1. for each descendant CAN station (argument of the loadDnto_ macro), do:
   • repeat:
     1. open the next executive file (which is passed on the command line to the "root" executive)
     2. send an 8-bytes "prefix" frame with the descendant SID in the 4 first bytes of the frame data field, and with the 32 bits big-endian executive length in the 4 last bytes of the frame data field (the SID is translated from the descendant processor name which is passed as argument of the loadDnto_ macro, and the executive length is stored and transmitted together with the executive data)
     3. while the remaining length of executive data is not null, do:
        • wait for a one-byte frame with the first byte containing a number of frames that the descendant is ready to receive (flow control)
        • read the next executive data bytes to fill and send that number of 8-bytes frames (except the very last frame which may contain less than 8 bytes), and decrement correspondingly the remaining length of executive data
     4. endwhile
     5. close the executive file, and wait for a "request" frame containing one non-null (resp. null) byte if the descendant station requests another (resp. no more) executive to forward
   • until no more executive is requested by the descendant station
2. endfor (continue with the next descendant CAN station)
3. when the last CAN station requests no more executive to forward, send a "prefix" frame with 8 null bytes, to signal that the download process is finished, i.e. that the executive code generated by the loadFrom_ macro may terminate, and that the executive may proceed with the application's code and communications
4. the loadDnto_ code of the ascendant CAN station terminates here, and the executive proceeds with the application's code and communications.

Descendant Station Boot-Loader Process

The boot-loader process is the following for each descendant CAN station:

• initialize the CAN interface
• repeat:
  1. wait for an 8-bytes "prefix" frame, with an SID in the 4 first bytes of the frame data field, and with a 32 bits big-endian executive length in the 4 last bytes of the frame data field
  2. if the prefix frame has a null executive length, start-without-loading, i.e. instead of waiting for an executive to download, use the executive available in FLASH (that was stored there before the boot during a previous download), i.e. jump to its entry point also stored in FLASH; otherwise proceed
  3. if the SID in the prefix frame is equal to the SID stored together with the resident boot-loader, break out of the enclosing repeat loop; otherwise proceed
  4. while the remaining length of executive data is not null, do:
     • wait for a 1-byte frame with the first byte containing a number of data frames to wait for (flow control)
     • wait for that number of frames, count 8 bytes per frame, and ignore their contents (the executive has been fully transferred when the accumulated count reaches the executive length transmitted in the "prefix" frame)
  5. endwhile
  6. wait for a 1-byte "request" frame, and ignore its contents
• endrepeat (repeat loop exited when SID match in prefix frame)
• repeat:
  1. send a 1-byte "request" frame with a non-null value in the first byte
  2. wait for a frame with the first (resp. last) 4 bytes in the data field containing the 32 bits start address (resp. memory size) of the next section of contiguous memory to download
  3. if the section's memory size is null, the executive is fully downloaded, and the start address is the entry point of the downloaded executive, so break out of the enclosing repeat loop; otherwise proceed
  4. while the section of memory has not been fully downloaded, do:
     • send a 1-byte frame with the first byte containing the number of data frames that may be successfully received without buffer overflow (flow control)
     • wait for that number of frames, each with 8 bytes per frame (except maybe the very last frame which may contain less than 8 bytes), and store their contents in memory at the next destination address, while incrementing the destination address and decrementing the count of remaining bytes
  5. endwhile
• endrepeat (repeat loop exited when null section size)
• the executive is now loaded in memory, save its entry point in FLASH for an eventual future start-without-loading, and jump to its entry point.

Descendant Station Download Process

The download process continues for each descendant CAN station in the initial phase of its downloaded executive (code generated by the loadFrom_ and loadDnto_ macros):

1. the executive entry point is generated by the "main_" macro, together with some processor-specific initializations (clear uninitialized data sections, initialize stack pointer, setup timer interrupt, and so on)
2. the "main_" macro is followed by "spawn_thread_" macros, to spawn a communication sequence for each communication media, among which the first one (which is here the CAN bus) is connected to the ascendant processor
3. the CAN communication sequence starts with initialization code, followed by the code generated by the "loadFrom_" macro, which first returns and is after called in turn by the code generated by each "loadDnto_" macro (if any) in the other communication sequences which are part of the download tree, such that the "loadDnto_" code sends the executives data that the "loadFrom_" code receives
4. for each loadDnto_ macro (executed after media initialization code called by each spawn_thread_ macro):
   • repeat:
     1. the loadDnto_ code requests the loadFrom_ code for another (resp. no more) executive to forward; if no more executive is requested, break out of the enclosing repeat loop; otherwise the CAN loadFrom_ code formats this request as a 1-byte "request" frame with a non-null value in the 1st byte
     2. the loadFrom_ code then waits for a "prefix" frame, with the local SID in the 4 first bytes of the frame data field, and with the 32 bits big-endian executive length in the 4 last bytes of the frame data field; the loadDnto_ code then knows the length of the executive to forward
     3. while the remaining length of the executive data is not null, do:
        • the CAN loadFrom_ code sends a 1-byte frame with the first byte containing a number of frames that may be received without memory overflow (flow control)
        • the CAN loadFrom_ code receives that number of frames, each with 8 bytes per frame, decrements correspondingly the remaining length of executive data, and the loadDnto_ code forwards these executive bytes
     4. endwhile
   • endrepeat (repeat loop exited when no more forward request from loadDnto_)
5. endfor (the loadFrom_ code interacts with the next loadDnto_ code)
6. when the loadFrom_ code has finished interacting with the last loadDnto_ code, the loadFrom_ code sends a 1-byte "request" frame with a nul byte, to signal the ascendant processor that no more executive is requested to forward; then the loadFrom_ code must wait until all the other executives are downloaded:
7. repeat:
   • wait for a "prefix" frame, with an SID in the 4 first bytes of the frame data field, and with the 32 bits big-endian executive length in the 4 last bytes of the frame data field
   • if the data field is empty, break out of the enclosing repeat loop, otherwise proceed
   • while the remaining length of executive data is not null, do:
     1. wait for a 1-byte frame with the first byte containing a number of data frames to wait for (flow control)
     2. wait for that number of frames, ignore their contents, and decrement correspondingly the remaining length of executive data
   • endwhile
   • wait for a 1-byte "request" frame, and ignore its contents
8. endrepeat (repeat loop exited when empty data field in prefix frame)
9. the loadFrom_ code terminates here, and the CAN communication sequence proceeds with application communications.

Descendant Station Executive Format

From the CAN boot-loader specification, we can derive the executive format for each processor booted through the CAN:

1. 32 bits big-edian total length of the following executive components:
2. for each section of contiguous memory to download: (note that some sections are uninitialized, and therefore not downloaded)
   1. section's 32 bits start address
   2. section's 32 bits size in bytes
   3. section's initial contents
3. endfor
4. 32 bits entry point address
5. 32 bits null (last section's size)