Changes between Version 11 and Version 12 of Hardware/jCM/dCM3/cSoftware


Ignore:
Timestamp:
Dec 16, 2011, 9:18:00 PM (13 years ago)
Author:
Ilya Chigirev
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Hardware/jCM/dCM3/cSoftware

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