You are here: CSP Developer’s Guide: Overview > 3 Getting Started > Downloading System Software
Overview
To download system software Version 5.5 or above, you must use the TFTP Download method. There are two means of initiating a download.
• BOOTP: Initiated by sending a BOOTP Request to a BOOTP Server
• Host: Initiated by sending a TFTP Manage API message to the CSP.
Download the Matrix Controller load and all other card loads from a TFTP server.
Table 3-1 Download Method - Considerations
Method |
TFTP |
TFTP |
BOOTP |
TFTP Manage Message |
Storing of .bin files |
---|---|---|---|---|---|
Full TFTP |
Yes |
Yes |
Yes |
Only required to query TFTP configuration. |
all required .bin files stored on TFTP Server |
Full TFTP |
Yes |
Yes |
No |
Required to initiate download and to query TFTP configuration. |
all required .bin files stored on TFTP Server |
Full TFTP Downloading requires the Matrix Controller card.
With the Full TFTP Downloading method, all card loads are stored on a TFTP server and retrieved by the CSP via TFTP. You must modify the default TFTP Configuration File to indicate the individual card loads to be downloaded for your configuration.
To implement Full TFTP downloading, follow the steps below.
1. Install and configure a TFTP Server (see Installing and Configuring a TFTP Server.
2. Modify the default TFTP configuration file according to your configuration (see Creating a TFTP Configuration File).
3. Copy the TFTP configuration file to the TFTP Server.
4. Copy the individual software .bin files for the cards you require to the TFTP Server.
You are now ready to initiate a download. See Initiating a Download.
Figure 3-6 Full TFTP Configuration
You can initiate a download using either a BOOTP server or the host.
Full TFTP Downloading Using BOOTP Response message shows the sequence for downloading system software files using the Full TFTP Downloading method and a BOOTP server.
Figure 3-7 Full TFTP Downloading Using BOOTP Response message
Full TFTP Downloading Using TFTP Manage API message shows a Full TFTP download initiated by the host using the TFTP Manage API message. See Using the TFTP Manage Message.
Figure 3-8 Full TFTP Downloading Using TFTP Manage API message
Downloading the Matrix Controller .bin File
Follow the step below to download the Matrix Controller .bin file from the host to the CSP using the download API messages.
1. Send the Clear System Software message to clear the existing software load, if any.
2. Reset the Matrix Controller by either pressing the reset button or sending the Reset Matrix message.
3. Send the Download Begin BRecord.
4. Use Download BRecord messages. Copy the file data into a series of Download BRecord messages. The host must send the B records in the exact order in which they exist in the file.
5. Send the Download Complete message. This message indicates that the host has sent all download messages. Once received, the CSP validates the software load and acknowledgments with either a success or error status. If the host receives an error status, repeat the system software download process again starting from the Download Begin message.
If the download is successful, the Matrix Controller executes the download code.
The Download Complete message includes a timestamp from the host. The host uses the timestamp to determine the most recent download in a redundant system.
6. Download other card loads using TFTP.
The host must follow each download message with another download message or a Download Complete message within five minutes, or the download aborts. For example, when a Download Begin BRecord is sent, a Download BRecord must follow within five minutes. The Download BRecord must be followed by either another Download BRecord or Download Complete within five minutes.
When downloading system software, do not have more than 25 outstanding (unacknowledged) messages at one time or a Matrix Controller fault will occur.
When the boot loader starts the system software, the CSP performs initialization and configuration tasks. These include downloading and validating the downloads on all the cards. As it performs this initialization, the CSP sends the host a Card Status Report message for each card it finds.
When initialization is complete, the CSP sends a Poll message to the host with the Ready For Configuration bit set and the host can begin configuration. If the CSP is part of an EXNET configuration and uses fiber optic communications, only a Node Status Report message returns after initializing. The host must issue the Assign Logical Node ID message before polling begins.
The system software runs in several states that the CSP identifies and sends to the host in Poll messages. Even if polling is disabled, the CSP sends a Poll message to the host every time the system software changes states. The host must react appropriately to changes in the system software state in order to start the system and keep it running. In a redundant system, Poll messages are sent from both Matrix Controller cards.
To read BRecords out of the *.bin file, perform the following steps:
1. Open the file as a binary file.
2. Read from the file with ten bytes (ten bytes is the minimum number needed to make a complete BRecord, with no Data field).
3. Read from the file the number of bytes specified in the Length field.
4. Add the bytes in the Length field to the first ten bytes. The combined data constitutes one complete BRecord.
Figure 3-9 BRecord Format
Content |
Byte |
Field Name |
---|---|---|
’B’ |
0 |
BRecord Identifier |
tt |
1 |
BRecord Type (See Below) |
0x00 |
2 |
Reserved (Must be 0) |
ll |
3 |
BRecord Length (n) |
aa |
4 |
BRecord Address (MSB) |
aa |
5 |
BRecord Address |
aa |
6 |
BRecord Address |
aa |
7 |
BRecord Address (LSB) |
dd |
8 |
BRecord Data[0] (Optional) |
dd |
9 |
BRecord Data[1] (Optional) |
: |
: |
: |
dd |
7+n |
BRecord Data[n] (Optional) |
cc |
8+n |
Checksum (MSB) |
cc |
9+n |
Checksum (LSB) |
There are four types of BRecord (see table below). Each type is identified by a value. All BRecords include fields for BRecord Identifier, Type, Length, Address and Checksum. The Header BRecord and Data BRecord types also contain a variable number of data bytes.
Table 3-2 BRecords Type
Type |
Field |
Description |
---|---|---|
0x00 |
Header |
Header record for a BRecord module. It contains data bytes. |
0x05 |
Record Count |
BRecord that verifies the number of data records preceding it; it contains no data bytes. |
0x10 |
Data BRecord |
BRecord that contains the actual download data; it contains data bytes. |
0x11 |
Terminator |
BRecord that marks the end of a BRecord module; it contains no data bytes. |
Additional BRecord Fields
The remaining BRecord fields are shown in the table below.
Table 3-3 BRecord Fields
Field |
Description |
---|---|
Length |
A byte that represents the number of data bytes in the data of the BRecord. BRecords without data bytes have the Length field set to zero. |
Address |
A long word that specifies the data bytes location in memory for data BRecords. In Record Count BRecords, the Address field contains the number of data records preceding it. In Terminator Records, the Address field has no significance. The most significant byte of the Address field is sent first. |
Data |
The Data field contains the data bytes for the download. The first data byte will be placed at the address specified in the Address field. The Length field specifies how many data bytes are in the BRecord. |
Checksum |
The Checksum field is a word that contains the sum of all of the preceding bytes in the BRecord. The most significant byte of the Checksum field is sent first. |