[Home] [Index] [Loader] [Glossary]

CAN Boot-Loader and Downloader Specification

The latest modifications are underlined.

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:
  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:

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):
  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:
  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.
Note that if the processor is a leaf node of the download tree, its executive will contain no loadDnto_ macro, so the "for each loadDnto_ macro" loop will be empty.

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)
Note that the sections' start address, size, and contents, and the entry point address must be encoded as expected by the destination boot-loader, i.e. with the processor's native "endianness".


[Home] [Index] [Loader] [Glossary]

Last update: 2000/04/17 by: syndex-support@inria.fr