| 5 | | === Requirements of Software === |
| 6 | | |
| 7 | | * HTML node control |
| 8 | | * Turn on and off node via HTML address |
| 9 | | * UDP control |
| 10 | | * connect to CMC |
| 11 | | * periodically send status packets |
| 12 | | * self registration |
| 13 | | * commands issued and responded to over UDP |
| 14 | | * Watchdog timer |
| 15 | | * update over HTML command |
| 16 | | |
| 17 | | === I2C protocol === |
| 18 | | The lantronix Xport AR does not come with a native I2C bus to the I2C communication between the node ID box and the hardware monitor chip (DS1780E) must be accomplished through bit-banging. The configuration of the CM is that of one master and two slaves (NodeID box and DS1780E). |
| 19 | | |
| 20 | | |
| | 5 | 4. Chassis Manager Software Description |
| | 6 | As mentioned previously software for the CM3 is developed in the Paradigm C++ Pro |
| | 7 | programing environment, and uses the Lantronix XPort AR SDK. At the time of this |
| | 8 | documents writing the SDK being used was release v5.2.0.0 R21. The CM3 works |
| | 9 | completely independently from the host node, and as soon as power is applied the native |
| | 10 | Lantronix XPort AR functions, such as network connectivity, start and then the custom |
| | 11 | written CM software loads. |
| | 12 | 4.1. Files |
| | 13 | The following is a list of the basic files that are in the SVN repository, and what functionality |
| | 14 | they contain |
| | 15 | CM3 |
| | 16 | Initialization of the CM3, XML configuration, and the main program which runs |
| | 17 | the two primary threads |
| | 18 | CM3_CLI |
| | 19 | Sets up the command line interface (CLI) structure, as well as defining the functions |
| | 20 | call-backs for each command in the CLI |
| | 21 | CM3_COMMAND |
| | 22 | There are the functions that actually execute the commands, whether they be |
| | 23 | called by HTTP, CLI, or UDP |
| | 24 | CM3_COMMUNICATION |
| | 25 | Opens the UDP socket |
| | 26 | CM3_HTTP |
| | 27 | creates the HTTP pages and function call-backs to enable HTTP commands |
| | 28 | CM3_I2C |
| | 29 | Presently unused other than containing functions that read the hardware status and |
| | 30 | the 5V monitoring line, this should be done over I2C through the DS1780 chip, |
| | 31 | but I2C is non-operational |
| | 32 | CM3_IDENTITY |
| | 33 | Contains functions that query the identifying features of the CM and node, like |
| | 34 | location, IP address, MAC address, etc. |
| | 35 | Ilya Chigirev WINLAB, Rutgers University |
| | 36 | 4. Chassis Manager Software Description 16 |
| | 37 | CM3_UDP |
| | 38 | Where the UDP thread functions are defines, as well as any other functions that |
| | 39 | process UDP information. |
| | 40 | 4.2. Initialization |
| | 41 | Upon startup the CM3 will fist contact broadcast over the network to discover the IP |
| | 42 | address that should belong to it. Assuming that the MAC address is already in DHCP, |
| | 43 | an IP address will be assigned to it, and from there the custom CM3 software takes over. |
| | 44 | Much of the configuration of the device is done through the XML configuration method. |
| | 45 | The following are configured through XML: |
| | 46 | Serial line |
| | 47 | GPIOs |
| | 48 | Telnet ports |
| | 49 | After XML configuration is completed the CM3 will populate the network information |
| | 50 | back into variables set up in software. This is because a lot of the network information |
| | 51 | is only available through the XML configuration file and so to recollect it each time |
| | 52 | you need it takes a long time. The CM3 then sets up the HTTP commands, which allow |
| | 53 | some basic functions of the CM3 to be executed of HTTP, the custom command line |
| | 54 | interface for the CM3, as described in table 2, and the user datagram protocol (UDP) |
| | 55 | socket. |
| | 56 | 4.3. UDP |
| | 57 | Once the UDP socket is opened two threads are opened that run side by side. The |
| | 58 | first is udpListen(), which is the thread that monitors the UDP socket for incoming |
| | 59 | packets. Once a packet is received the thread checks for valid CM packet structure and |
| | 60 | proceeds to act accordingly if it is. The details of the communication protocol are given |
| | 61 | in section 5. |
| | 62 | The other thread that is opened is udpPkt(). udpPkt() is the function that is responsible |
| | 63 | for sending registration and status packets. Initially the function will send out |
| | 64 | registration packets, until it gets a registration ACK, and then a status update packet |
| | 65 | every 20 seconds. If the CM sends out 3 status update packets and does not receive an |
| | 66 | ACK from the CMC, it will go back to the assumption that it is no longer registered in |
| | 67 | the CMC and send out registation packets again. Again, the details of the UDP communication |
| | 68 | protocol are described in greater detail in section 5. The two UDP threads |
| | 69 | are responsible for most of the functionality of the CM3 as the majority of commands |
| | 70 | come from the experiment controller through the CMC over the UDP lines. HTTP and |
| | 71 | CLI commands are added functionality for when there is no CMC. |
| | 72 | Ilya Chigirev WINLAB, Rutgers University |
| | 73 | 4. Chassis Manager Software Description 17 |
| | 74 | 4.4. Loading software |
| | 75 | There are two primary methods to reflash a CM3, over the network and also through |
| | 76 | the serial port. This section will describe how to load new firmware onto the device |
| | 77 | using both methods. The latest ’known good image’ can always be found on the SVN |
| | 78 | Repository |
| | 79 | 4.4.1. Flashing firmware over network |
| | 80 | 1. open FTP session directly to the CM Lantronix device in terminal client |
| | 81 | ftp xxx.xxx.xxx.xxx |
| | 82 | 2. when prompted for the username and password enter the following |
| | 83 | username: admin |
| | 84 | password: PASS |
| | 85 | 3. using the image taken from the SVN repository REV_A_B_C.rom.gz |
| | 86 | put REV_A_B_C.rom.gz xport_ar.rom.gz |
| | 87 | The image must be sent to the Xpor AR named xport_ar.rom.gz, otherwise the |
| | 88 | device will not recognize it as new firmware and will not re-flash. Re-flashing the device |
| | 89 | will take a few minutes, it will reset itself and should come back online with no issues. |
| | 90 | 4.4.2. Flashing firmware over serial |
| | 91 | Re-flashing as CM over the serial port should be done when the node is not accessible |
| | 92 | aver the network, it is a generally slower method than via FTP. Before you can recover |
| | 93 | the firmware over serial you will need to install Device Installer on your PC. Device |
| | 94 | Installer is free to download off the lantronix website. |
| | 95 | 1. Open DeviceInstaller |
| | 96 | 2. Go to ’Tools’->’Advanced’->’Recover Firmware’ (or simply the F8 key) |
| | 97 | 3. Configure the options, and hit OK to load the image |
| | 98 | a) Choose the COM port being used |
| | 99 | b) Select "Xport AR A1" as the device |
| | 100 | c) Make sure that the "Erase all flash" option is checked |
| | 101 | d) Enter the path of the image to be loaded |
| | 102 | The program will prompt you to power off the device, you can just ignore this and |
| | 103 | hit next. The serial recovery will have started, but you must still power cycle the device |
| | 104 | before the transfer begins, either hit the reset button on the CM or just pull and reapply |
| | 105 | the power to the CM. |
