ETHERNET PIC CONTROLLER (NETPIC) Manual

Copyright (c) 2001 EIX Ltd

Hardware - Setting up

After all the PCB has been wired up and connected together, plug the PC ISA Ethernet card into the socket and power the board with 5V, power consumption should be about 100mA or less, depending on the ISA card used. One of the LEDs (on PIC port C4) should be flashing at about once per second. Connect the unit to your LAN via the coax cable and a termination resistor if necessary.

 

 

 

First Tests

The board holds all its IP addresses in EEPROM. When started for the first time, the following defaults are loaded:

                        IP address                                 192.168.0.15

                        Ethernet HW address                 0x455448504943            i.e. “NETPIC”

You can reinstate these default values by holding pin C6 of the 16F877 down while resetting the board.

From your PC, open a DOS console box and enter:

c:>arp -a

The most likely response could be: No ARP entries found.

Then try:

c:>ping 192.168.0.15

If everything is working correctly, the response should be:

Pinging 192.168.0.15 with 32 bytes of data

Reply from 192.168.0.15. bytes=32, time<=10mS TTL=128

Then, try again

c:>arp -a

The response should now be:

Internet address Physical address           type

192.168.0.15      45-54-48-50-49-43          dynamic

This will show that our board has been recognised by the network.

 

Installation Problems

If you are having any trouble, try the following.

- If the LED connected to PIC port C5 is not flashing: Remove the ISA card, if the LED is still not flashing, there is a problem with the PIC, crystal, or the power supply (there isn't much else to go wrong at this point). If you have a scope check for a 20MHz waveform at pins 13,14 of the PIC. Also ensure the reset pin (pin 1) and port C6 (pin 25) are high, and not held low by the DIL switch.

- Run program "877driver.exe" on your PC. Connect the serial port from your computer to the NETPIC serial interface. Remove the ISA card and reset NETPIC (by reapplying power supply, or bringing low the reset line (pin 1). The PC screen should display the four characters <""> denoting that at least the PIC and the serial port are working. (make sure the "rx hex" tick is reset on the PC screen) and that all the DIL switches are in the OFF position..

- Plug in the ISA card. Reset NETPIC again.The PC screen should now display <Pp>. denoting it has detected the 8019AS chipset. The green led on the ISA card may flash at this stage. You may get a different pair of characters if you are using a different card. If you get nothing, your card may not be configured properly.

 

- Some of the older ISA cards have jumper settings. make sure these are set to the 0x300 base address range, no IRQ (any will do), and 8 bit transfers.

- Reconfiguring your card. If your ISA card is PnP (Plug and Play) and it has been used before, it may need to be reconfigured. This is because the PnP system may have reconfigured the card base address to other than 0x300. You should only do this if you are fully conversant with your PC and its settings. Any mistake may cause your PC to fail to recognise its existing network cards if there were any present. You will need a PC with PnP enabled, ideally W95 or W98. Fit the ISA card in one of the spare slots, and start the machine. The PnP system will recognise the card and invite you to install it. Use the standard Windows drivers for NE2000 compatible cards. At some stage you may be invited to change the basic settings (if not, you can do this from the control panel). From the basic settings, change the address range for the card to 0x300-0x30F. There is no need to change the Interrupt settings.

Alternatively, it is possible to hardwire one of the pins in the 8019AS to ignore PnP, but you must consult the IC data manual, as the device is supplied in many different package formats.

 

Using "877Driver.exe"

This program is mainly used to test and configure NETPIC.

The Dialog screen is divided into three areas:

Top Right: General purpose buttons to select a COM port (1 to 4), clear the screen and exit the program.

Top Left: Transmit packet: The various buttons and options are used to generate a byte pattern which is then sent to the PIC when clicking on the "xmit" button. You can enter your own sequence on the long edit box (as ASCII or as hex pairs, depending on the tick selection). Clicking or selecting any of the other options will create pre-cooked patterns as required by the PIC. The formats are discussed in the next section.

One of the most useful options is "query vars", this causes the PIC to return a 20 byte sequence corresponding to its internal address settings.

Bottom: Received data: this is displayed in both raw and "decoded" form. Use the "clear" buttons to clear the box when it gets too full.

 

Using "877Demo.exe"

This program demonstrates simple UDP communications between the NETPIC controller and Windows. It can be used to show that the controller is working properly,  877Demo is nothing more than an advanced version of TestEth.c. You could enhance TestEth.c, to this level of functionality with relatively little extra coding effort.

First ensure the NETPIC controller is set for UDP demo mode. This can be done by sending the two byte command <CB><08> from 877Driver.exe (see above), or by setting the DIL switch to all OFF (see diagram), and resetting NETPIC.

Run 877Demo, and ensure the IP address and the port number on the screen correspond to that used by the NETPIC controller (usually 192.168.0.15, and port 1281).

Set some of the bit ticks in the "remote I/O" section, and click on the "Output to Port C", and the "Port A analogue enable" ticks as well.

Press the "Send Request" button. This will generate a four byte payload UDP message to be sent to the NETPIC remote at port 1281.  If all is well, NETPIC will set its output ports (light the LEDs), sense the voltage at the trimpot on bit 0 of PORTA, and reply with another four byte UDP datagram to the PC.  The PC will decode the reply and display the analogue voltage on the screen.

NetPicDemo first sends an ARP packet to the controller to find its hardware address, then continues by sending the UDP datagram with 4 bytes of payload data.


BASIC OPERATION OF CONTROLLER

General Software operational sequence (refer to the following flow diagram)

 

On Power on:

If just after reset, port C6 is low, the following defaults are installed in the EEPROM.

            hmaddr             0x4E4554504943                       i.e. "NETPIC"

            Ipmaddr            0xC0A8000F                             i.e. "192.168.0.15"

            gstatus             0x00                                         57600bps, demo mode

Otherwise, The above are loaded from the previously stored EEPROM:

            hmaddr             My hardware MAC Ethernet address        6 bytes

            ipmadd              My IP address                                       4 bytes

            gstatus             Current setup conditions

The following variables are also loaded from EEPROM, and are usually stored as a remainder from the last operation performed

            htaddr               Last destination HA address contacted

            iptaddr              Last destination IP address contacted

The DIL switch is read, and internal flags are set as follows:

            SW7     Serial port speed:           off= 5700           on=2400

            SW6     Start up mode                off=UDP demo   on=transparent mode

            SW5     not used

The program now enters an endless loop, sensing the input Ethernet buffer and waiting for user characters on the serial port. The LED heartbeat lamp is flashed every second or so to show the unit is operational.

There are three relevant ""Events" a this point:

            Receiving a data packet from the Ethernet wire

            Receiving a character from the user's serial port.

            Internal timer counter overflows or reaches end count.

1 when a frame has been received into the Ethernet buffer:

Refer to the figure above for the internal data flow. This flow is controlled by bit flags in ram location gstatus. 

If bit flag gstatus,0 is set:

The received frame is sent to the user output serial port in encoded form (see section on packet encoding for the actual format), no other processing is done on incoming data . This option is useful for using the device as a simple network monitor. Two other flags are also relevant for this option: if bit flag gstatus,4 is set, only the first 64 bytes of every frame are sent to the serial port (e.g. headers only and to avoid sending long data blocks). If bit flag gstatus,1 is set, the Ethernet chip will accept all frames i.e. not just those addressed to it. This feature is known as "promiscuous mode". This allows all data in the network to be accepted by the chip.

 

If bit flag gstatus,0 is reset:

The controller will process the incoming frame. The frame will be silently discarded if any of the following conditions are met, otherwise the payload is passed on to the next level::

            The ethernet trailing CRC checksum word was in error

            The Frame is not a broadcast, or is not addressed to our MAC address (unless bit flag gstatus,1 is set, in which case it will be accepted)

            The Frame type is other than ARP or IP (codes 0x800 or 0x806)

If bit flag gstatus,5 is reset, the chip will process incoming ARP frames, otherwise they will be ignored. ARP frames have a type code of 0x800, and are used to determine the hardware address of a card from a given IP address. ARP packets are usually broadcast from a remote workstation, only the station with the correct IP address match will reply to the ARP request with a data packet containing its own hardware address. A typical ARP request packets is as follows:

0xffffff

srceHA

0x806

flags

srce HA

srce IP

trgt HA

trgt IP

Therefore, if bit flag gstatus,5 is reset, and the payload packet was an ARP "request" packet, and the target IP address matches with ours (i.e.  trgtIP = ipmadd), then

            - An ARP reply is sent back.

- The single character 'A' is sent to the user serial port. This notifies the user that an external ARP request  was received.

If on the other hand, the received packet was an ARP "reply" (usually in response to our unit sending a previous ARP request), and both target HA and IP address match with ours (i.e. destHA=hmaddr, and  trgtIP=ipmaddr), i.e. the received packet was:  

trgtHA

srceHA

0x806

flags

srce HA

srce IP

trgt HA

trgt IP

Then:

            - Our destination HA address is updated, ie htaddr=srceHA

            - A single character 'a' is sent to the user serial port

            - An internal bit flag  gethflag,0  is reset (this flag was set when the ARP request was  called by the user).

 

 


Generating an ARP "request":

We may need to generate an ARP request when we want to know the hardware (HA) address of a remote station. We can do this by sending the single letter command "A" to the serial port, the controller generates the ARP request. The general procedure is as follows:: User stores the required destination IP address in iptaddr User generates and transmits and ARP request packet (command 'A') Controller chip transmits request and sets bit flag gethflag,0 to 1. Some time later, an ARP reply may be received from remote, Flag gethflag,0 will then be reset, the remote HA address will be stored in htaddr. Controller chip sends ascii code 'a' to user serial port. A "no reply" can be sensed by either not receiving the 'a' command or by flag gethflag,0 not resetting. Another ARP should be sent or the transaction aborted.




 

If the received payload was an IP datagram:

If bit flag gstatus,6 is set,  the IP message is sent to the user serial port in encoded form, no further processing willl be done by the controller chip.

If bit flag gstatus,6 is reset,  the controller will process the IP message. The IP header is checked for consistency, and packets will be discarded if the following conditions are met, otherwise the payload is passed on to the next stage.

            IP header checksum in error

            Destination IP address not same as our IP address (ipmadd)

            Protocol none of 01(ICMP), 06(TCP), 11h(UDP).

            Fragmentation offset is not zero

            The "more fragments" bit flag is set.

If the IP payload is an ICMP message:

If bit flag gstatus,7 is set, the ICMP message is sent to the user serial port in encoded form, no other ICMP processing is performed within the chip. This feature can be used to externally process ICMP data (for developing custom PING and traceroute type programs) 

If bit flag gstatus,7 is reset, the controller will process the ICMP message as follows:

ICMP request (type = 0x08) 

            The message is echoed back to the remote workstation as a ICMP reply packet

            The single character 'H' is sent to the user serial port.

ICMP reply (type= 0x00)

            This is usually received in response to our PING request (see below)

            The internal flag gethflag,1 is reset (this flag was reset by our previous PING request)

            The single character 'h' is sent to the user serial port.

ICMP - other codes

            Three characters are sent to the user serial port:

            'g' followed by a type byte and a code byte.

            This allows for simple processing of incoming ICMP error messages

 


Generating a PING request:

We may want to send a PING message to another workstation This can be done by sending the single character command 'H' to the serial port. This also causes the internal flag gethflag,1 to be set, which is reset on reception of a correct PING reply. As an alternative, custom ICMP packets can be generated by sending direct encoded packet data to the serial port (see section on transmission).

 


 

If the IP payload is a UDP datagram:

If bit flag gstatus,3 is reset, the contents of the datagram are sent to the serial port in encoded form, no other UDP processing is performed within the chip.

If bit flag gstatus,3 is set, and  if the UDP packet was addressed to one of our enabled ports, some internal UDP processing will be done: For port 0x501 (1281 decimal), The internal I/O registers in the PIC are read or written to depending on the packets data, and a response packet is sent back to the source with the results of the readings. This forms the basis of a simple I/O gathering station using he few available I/O ports on the PIC (5 digital and 6 analogue).

If the IP payload is a TCP segment:

If bit flag gstatus,2 is reset: the contents of the segment are sent directly to the serial port in encoded form, no other TCP processing is performed within the chip.

If bit flag gstatus,2 is set, and if the TCP packet was addressed to port 0x502, the TCP state diagram will be enabled. This allows stream communications to and from the user's serial port.


TRANSMITTING DATA

User input serial port data is separated into commands and transmit data. Commands are single characters or string of characters used to set and read internal state variables and registers. Transmit data is a string of bytes encapsulated as packets with a special header and trailer code byte sequence. Transmit data bytes are sent to the Ethernet chip for transmission after removal from their packets.

Command Codes

The following commands are available:

            A                      Transmit ARP request

            H                      Transmit PING request

            Sxxxx               Enter our IP address (0x53 followed by 4 bytes)

            Dxxxx               Enter destination IP address (0x44 followed by 4 bytes)

            Bxxxxxx           Enter our HA address (0x42 followed by 6 bytes) (NOT IN DEMO VERSION)

            <CB><x>          Change status byte (i.e. 0xCB,0x00)

            <CD><<XX>      Set the TTL and TOS bytes (i.e. 0xCD, 0x80, 0x00)

Transmit Data Packets:

Blocks of data for transmission must be prepared by the user software in the correct format (see next section). The packet will be directed to different processing sections depending on the protocol used. The protocol byte is the byte after the packet first byte 0x7E:

Packet Encoding

User data packets must be differentiated from user commands and other data. A simple method for encapsulating blocks of data is used here. The format is very simple and easy to encode and decode, the basic format is as follows:

7E

protocol byte

...data......

7F

FF

The first byte is 7E hex, and denotes the start of a packet. This byte value does not occur in any of the command codes, or within any of the data itself so it uniquely denotes the start of a data block. Following the 0x7E is a single protocol byte, which is used to determine what type of data follows, the options are

            00         Raw Ethernet

            01         ICMP

            04         TCP + MSS payload

            05         TCP payload

            06         TCP

            10h       UDP payload

            11h       UDP

            xx         Others

The data section itself is of variable length. The terminator byte is 7Fhex, usually followed by an optional byte FFhex (which is used to denote that the packet was OK, and not in error), this last byte can be ignored in most cases.

Escape sequences are used in the main data stream to ensure that payload data bytes of the form 7D, 7E or 7F are converted to byte pairs 7D5D, 7D5E and 7D5F. This will ensure uniqueness of the header and terminator bytes.

This scheme is similar to the method used in PPP, with the only difference that the start and end packet markers are different (they are the same in PPP).

The user software will need to use the following scheme for decoding received packets:

            Wait till byte 7E is received, start the buffer

            Receive the next byte and save as the protocol code.

            Receive bytes, one by one

            If the received character is 7D, ignore it, and XOR the next with 0x20.

            Continue doing this until byte 7E is received 

            If the byte after the 7E is FE, the packet was bad, dump it or process it regardless.

The scheme for transmitting a packet:

At the start, send the two byte sequence 7E followed by the protocol code,  i.e. 00, 01, 04, 05,06, 10h or 11h as required  Transmit the data bytes one by one, if any of the bytes happens to be one of   7D,7E,7F, precede it with 7D and XOR the byte with 0x20, ie transmit the byte pairs 7D5D, 7D5E, or 7D5F instead.   To end, transmit the byte pair 7EFF

The Transmission Protocols

Protocol=0x00 (raw Ethernet):

The packet is sent to the Ethernet chip for direct transmission, no processing is done on the packet (apart from removing headers, trailers and the escape pairs). Note that these raw packets must contain full ethernet source and destination address headers as well as the user payload: The format is as follows (after removing 7E-7F encapsulation)

dest HA(6)

srce HA(6)

frame(2)

payload(4)

To comply with standard ethernet framing conventions, the packets must contain between 64 and 1500 bytes.

Protocols 0x01 (full ICMP), 0x06 (full TCP) and UDP(full 0x11)

The controller will add a 14 byte Ethernet header (using internal HA addresses 'hmaddr' for source and htaddr' for destination. It is assumed that the destination HA address has been previously obtained by the user with an ARP request command. Or a message from another workstation has been received, which will set the value automatically. The resulting Ethernet header is as follows:

:

htadd(6)

hmadd(6)

0x800

IP & user payload as below

The controller will also add a 20 byte IP header with the values generated as follows.

45

TOS

DG size

ID

flags & offsets

TTL

PCOL

IP checksum

source IP

dest IP

The controller will use internal user defined values for TTL and TOS. The ID is internally generated and automatically incremented for every transaction. The source IP address is taken from ipmadd and the destination IP address from iptadd. Checksum and other values are internally calculated.

Payload

User supplied Payload (ICMP/UDP/TCP)

Depending on the protocol used, the user will need to fill the payload with the correct sequence. In the case of ICMP, TCP and UDP, the controller will calculate all the  checksum and size entries, there is no need for the user to fill these fields. The fields supplied by the user must be as follows:

User supplied ICMP payload (protocol = 0x01)

TYPE(1)

CODE(1)

Checksum(2)

Options(4*n)

where:

            TYPE                Supplied by user

            CODE               Supplied by user

            Checksum         Calculated internally

            Options Data supplied by the user

User Supplied UDP datagram (protocol 0x11)

source port(2)

dest port(2)

UDP length(2)

checksum(2)

User data(4 * n)

Where:

            Source port       Supplied by user

            Dest port           Supplied by user

            UDP size          Calculated internally

            Checksum         Calculated internally

            User data          Supplied by user

User supplied TCP Segment (protocol 0x06)

source port(2)

dest port(2)

sequence number(4)

ack number(4)

offset(1)

flags(1)

window(2)

checksum(2)

urgent(2)

User data(4 * n)

Where:

            Source port       Supplied by user

            Dest port           Supplied by user

            Seq number       Supplied by user

            Ack number       Supplied by user

            offset                Supplied by user

            flags                 Supplied by user

            window              Supplied by user

            checksum         Calculated internally

            urgent               Supplied by user

            User data          Supplied by user

Protocol 10h (UDP payload)

This is similar to protocol 11h, but the user only provides the actual payload data for a UDP transaction. The Controller will add not only the IP header, but also the UDP header. The source port will be taken from tcpdport, and the destination port from tcpsport.  This protocol is used to reply to UDP transactions whwn the UDP socket is open (by setting bit flag gstatus,3.

Protocol 5 (TCP payload)

This is similar to protocol 6, but the user only provides the actual payload data for a TCP transaction. The Controller will add not only the IP header, but also the correctly formatted TCP header. The source port will be taken from tcpdport, and the destination port from tcpsport.  This protocol is used for stream transactions when a TCP socket has been opened (by setting bit flag gstatus,2.

 

 

Protocol 4 (TCP + OPTIONS payload)

This is similar to protocol 5 above, but with the added facility of options added to the header. This protocol is mainly used internally when opening a communications and for sending extra information such as MSS limits.


Examples of Use:

Simple Network Analyser

Flag gstatus must be set to 0x03, (optionally to 0x13 to limit data to 64 bytes per packet) . In this format, all incoming packets will be sent to the user serial port in encoded form, (see section on packet encoding for format). Having removed the headers and trailers and escape sequences, the resulting packet will contain the following fields, refer to any book on eternet  and IP for more details:

HA target addr(6)

HA source addr(6)

frame(6)

payload(N)

The HA target and source addresses are 6 bytes each, and correspond to the hardware addresses of ours and the remote ethernet cards in the network. The special target address FFFFFF is used for broadcast packets, usually associated with ARP requests. The frame code identifies the format of the payload, some of the most common codes in use are:

            0x800               IP packet (including ICMP/UDP/TCP

            0x806               ARP packet

The user software only needs to perform a simple tree decoding of the packet fields for display, including any filtering as required. Program "877driver.exe" demonstrates the use of the controller as a simple network analyser. Connect a spare serial port in your PC to the serial port in the controller, and fire the program. Note that because the speed restrictions on the serial port (max 57600bps), not all packets can be transferred, any overflows will just be dumped. The network analyser .is really for a network with relatively low usage.

Ping/traceroute program

A traceroute program is one that sends ICMP packets (ping) with various difefrent options and parameters in order to find out about routers and access to a particular destination. The most common parameters for validation are:

            TTL (time to live) byte

            TOS

            Options: e.g. number of data characters

           

Flag gstatus must be set to 0x80  The user software must ignore packets other than ICMP ones (the protocol byte after the 0x7E header will be 0x01), and be able to decode and process the incoming ICMP headers. The user software must also create fully formatted ICMP packets and send them to the controller using protocol 0x01. There is no need to check or calculate the checksum fields, as these will be handled automatically by the controller. The user software must also set any destination IP addresses with the command "Dxxxx", as well as using ARP requests to obtain any remote hardware addresses as required.

Free format UDP transactions

The controller provides two methods for UDP transactions, depending on whether the user wants to keep control of the headers, or wants to do transparent transactions. For free format UDP, flag gstatus must be set to 0x00. All arriving UDP packets (addressed to our IP address in ipmadd) will be sent directly to the user serial port. No checks will be made on destination port number, the user software will need to do this. The user packet (after removing 7E-7F encapsulation) will contain the following:

srce port(2)

dest port(2)

nr bytes(2)

checksum(2)

payload(n)

The source IP address is stored in the iptadd variable. The user software needs to check the first two bytes correspond to the port we want to receive on (they can be ignored in a simple system). 'Nr bytes' and 'checksum' can also be ignored.

When preparing a reply packet it should be formatted as follows:

dest port

srce port

nr bytes

checksum

payload

Note that the destination and source port numbers have been interchanged. There is no need to enter any data for length or checksum as these will be calculated and added automatically inside the chip. For transmission, the user software must generate a similar packet to the above, that includes source and destination port numbers must be included (they must be reversed!). There is no need to add size or checksum fields, these will be added and computed automatically by the controller.  When formatting the block using 7E-7F encapsulation, use the 0x11 protocol byte.

Transparent UDP

A simpler form of the above, where the UDP header is handled internally by the controller and only the final payload is passed on to the user. Flag gstatus must be set to 0x08. All UDP packets arriving addressed to our IP address, and with destination port number 0x5002 will be accepted, the clean payload is passed on to the user via the serial port. For transmission, the user only needs to create a packet with the data to be send (no UDP header information). When formatting the block using 7E-7F encapsulation, use the 0x10 protocol byte.

Free Format TCP

In a similar way to UDP, the controller provides two methods for TCP transactions, depending on whether the user wants to keep control of the headers, or wants to do transparent transactions. For free format TCP, flag gstatus must be set to 0x00. All arriving TCP packets (addressed to our IP address in ipmadd) will be sent directly to the user serial port. No checks will be made on destination port number, the user software will need to do this. The user packet (after removing 7E-7F encapsulation) will contain the following:

srce port(2)

dest port(2)

seqnr(4)

acknr(4)

flags(2)

window(2)

checksum(2)

urgentptr(2)

options(n)

payload(n)

The source IP address is stored in the iptadd variable. The user software needs to check the first two bytes correspond to the port we want to receive on (they can eb ignodred in a simple system). 'nrbytes' and 'checksum' can also be ignored. For transmission, the user software must generate a similar packet to the above, that includes source and destination port numbers must be included (they must be reversed!). There is no need to add size or checksum fields, which will be added automatically by the controller.  When formatting the block using 7E-7F encapsulation, use the 0x6 protocol byte.

Transparent TCP

A simpler form of the above, where the TCP transaction is handled internally by the controller and only the final payload is passed on to the user. Flag gstatus must be set to 0x04. All TCP packets arriving addressed to our IP address, and with destination port number 0x5003 will be accepted, the clean payload is passed on to the user via the serial port. For transmission, the user only needs to create a packet with the data to be send (no TCP header information). When formatting the block using 7E-7F encapsulation, use the 0x5 protocol byte.