Copyright © 2000, Aerospace Software Ltd.,
Calgary, Canada
217 Edgedale Gardens NW, Calgary, AB, T3A 4M7,
Canada
Fax: 403+241-8841, E-Mail: aerosoft@AerospaceSoftware.com,
Web: http://www.AerospaceSoftware.com
The design philosophy behind this program was to keep it straight and simple. The idea is to debug a protocol, not fight the tool. All controls and settings are permanently visible and only two communications ports are supported. More than two ports are seldom required in practice since one can only meaningfully debug one data link at a time and with many ports, the data display would become confusing, so two ports was set as the logical limit. You can run multiple instances of this program to debug 4 or more ports, but then you need a fast PC.
This program requires at least one standard PC serial communications adapter for RS232, RS422 or RS485 operation. RS232 is the common or garden variety serial port frequently built into a PC. If you need RS422 or RS485, you'll know it.
The display can be toggled between Hexadecimal and ASCII display modes. This allows easy analysis of serial communications between two devices.
If a comport is working properly, it's status checkbox will be ticked. If a comport is not present, or already in use by another program, then the status checkbox will be greyed and that port will be ignored.
WinHexCom is normally in receive mode, with RTS disabled. When you transmit a message from WinHexCom, it enables the RTS pin for the duration of the message, then disables it again. This allows one to debug two half duplex RS485 channels effectively, using COM1 and COM2 to full capacity. The communication is displayed in 4 colours, to enable one to see which port sent or received what.
In Hexadecimal mode, the message string should be entered as pairs of numbers delimited with spaces and is converted to binary before transmission. Non hexadecimal characters are ignored. WinHexCom performs a round trip conversion and will echo the exact transmitted data on the screen. If the screen does not show the same message you entered in the send message box, then you have to fix the format and send it again. In Hexadecimal mode, WinHexCom will not add anything to the message string - it will be sent as is.
Note that the transmission order is always Left to Right and Least Significant Bit First. In order to manualy build a valid HDLC message, one really has to keep one's wits together. A complicated HDLC message is best figured out on paper first before you enter it.
Whenever a new, different message is entered, the history list will be updated. Any message in the list can be selected for transmission. WinHexCom will not save the same message more than once. Select the comport you want to transmit on, by clicking the relevant Radio Button.
Note that if a comport is unavailable, or if the screen is stopped with the stop button, or if a file transfer is in progress using X-modem or Binary Dump, the send button will be inhibited.
You can use the checksum calculator to verify incoming data or to compute checksums for messages that you want to send. Use the mouse to highlight a message on the screen and then copy and paste it to the Send Message box (Ctrl-C to copy and Ctrl-V to paste). Once the message is in the Send Message box, you can use the checksum calculator to calculate the frame check sequence.
The Framer will always build correct messages. In order to test the error handling of a protocol, one does have to create and send bad messages as well. You can create a message frame and then go back and change it in the send message box to add some bit errors, or to add garbage in front or after the message before transmitting it.
Some default interlocks were added to make WinHexCom easier to use:
If you select a new Frame Type, the Checksum and Display View boxes
will change to the settings normally associated with that Frame Type.
Eg.: If you select a PPP Frame Type, the Display View will change to PPP and the Checksum will change to CRC16.
You can then go and change it if you want. It is therefore
possible to use CRC32 with the PPP frame or to view the raw data in Hexadecimal
mode. You just have to select those after selecting the Frame Type.
Each frame starts and ends with a unique flag character 7EH. There may be one or more flags and idle bits between frames.
Transparancy is achieved through zero bit insertion. A Flag character contains a sequence of six 1 bits. Therefore, if a data sequence results in more than 5 consecutive 1 bits, a zero is inserted. This creates a small overhead, but the efficiency is far better than that of PPP.
The synchronous channel idles either with Flag characters or with 1 bits. If eight or more consecutive 1 bits are received, it indicates an abort command and the current packet (if any) should be discarded.
On transmission, the CRC is calculated first, then the zero bit insertion is done and finally the flags are added, after which the packet is transmitted flag to flag. On receive, the data is received flag to flag, the flags are stripped, then the 0 bit stuffing is removed, after which the CRC can be verified. The framer function is simple enough that it can be done efficiently in hardware.
Flag Data... CRC Low, CRC High, Flag
Where,
Flag = 7EH
Data = 00H..FFH
CRC = ITU CRC16, polynomial 8408H, initial value FFFFH, final value
1's compliment, constant result FB08H
Transmission order = Left to right, each byte LSB first
Note that the standard PC serial port operates in asynchronous mode
only. To parse synchronous HDLC you have to provide some hardware
to interface the synchronous stream with your PC serial adapter.
All that this hardware needs to do, is to chop the stream into bytes and
resend it with a UART and RS232 driver. The synchronous HDLC handler
of WinHexCom will then use the HDLC flags to figure out exactly where a
packet starts/stops. This allows your network debug interface to
be a very simple design.
Each frame starts and ends with a unique flag character 7EH. There may be one or more flags between frames.
Transparancy is achieved with a two pronged approach. A PPP Escape character 7DH is stuffed in to identify data bytes that equal a flag, a PPP Escape, or any character smaller than 20H, while bit 6 of the offending character is inverted, thus changing it into something else.
This allows the packet to pass through a channel without being affected by control character handling (XON, XOF, CAN etc. can all cause problems on some channels) and ensures that the start and end flags can be uniquely identified.
On transmission, the CRC is calculated first, then the Escape stuffing and bit inversion is done and finally the flags are added, after which the packet is transmitted flag to flag. On receive, the data is received flag to flag, the flags are stripped, then the stuffing is removed and the bit inversion undone, after which the CRC can be verified. The framer function is simple enough that it can be done efficiently in hardware.
Flag Data... CRC Low, CRC High, Flag
Where,
Flag = 7EH
PPP Escape = 7DH
Data = 00H..FFH
CRC = ITU CRC16, polynomial 8408H, initial value FFFFH, final value
1's compliment, constant result FB08H
Transmission order = Left to right, each byte LSB first
Example message: 11 22 33 44 55 66 77 88 99
Example message with frame: 7E 7D 51 22 33 44 55 66 77
88 99 99 14 7E
Each packet starts with a synchronization character EEH (Not unique, but a high value, which is unlikely to equal a code, length or data byte), followed by the message Code and Length. The MSB of the message code is used as a packet counter and is toggled for each new message - kept the same for a retry. If a message is received with the same sequence number as the previous, the message is acknowledged, but discarded.
ACK, NAK and periodic HELLO messages have the Codes 7DH, 7EH and 7FH respectively. These messages have exactly the same form as the data messages, which keeps the protocol simple and regular.
In the event of an error, a message can be retried up to 2 times. When nothing has been transmitted for a while, a HELLO message is stuffed in, to show that the system is still alive. ACK, NAK and HELLO messages are not acknowledged, but a HELLO message is replied to once, with another HELLO message.
The ICNI message frame does not have a unique end of frame flag. One has to rely on the message length and a timeout. The version 3.00 parser looks at the length only. So, if you don't seem to receive anything, it usually means that the packet length is wrong. Remember that if you change the Screen View to Hexadecimal, then you will see everything in raw form, which will indicate why packets are missing.
As it is a common mistake to enter the wrong message length with this protocol, the Framer will recalculate the message length when it is framed. This is in keeping with the idea that the Framer will always build correct messages. If you want a message with a bad length, you have to change the message manually in the Send Box.
Synch Code Length Data... Checksum
Where,
Synch = EEH
Code = 00H..7FH, with the MSB used as a single bit packet counter
Length = 00H..FFH of all Data bytes to follow
Data = 00H..FFH
Sum = Modulo 2 sum (XOR) of all bytes excluding Synch
Transmission order = Left to right, each byte LSB first
Example message: 11 05 11 22 33 44 55
Example message with frame: EE 11 05 11 22 33 44 55 05
Due to a Windows 9x memory manager bug, the screen is not quite 'bottomless'. The screen will buffer up at most 96kB of data, at which point it will be flushed and fill up again. You can stop the screen output and scroll backwards in the screen buffer at any time.
The Run/Stop buttons control the screen output. If the stop button is pressed, the screen and logger will stop, but up to 4kB of data will still be buffered and sent to the screen and log file when the run button is pressed. This allows one to momentarily stop the screen to inspect an interesting event, without losing any important data. If the system is stopped for a long period of time, the buffers may overrun. In version 3.00, there is still a bug with this function and when the Run button is clicked, the program may terminate.
If you toggle the the Screen View mode during operation, it will only affect data from that point on. WinHexCom will not rewrite the entire screen. This allows one to view startup messages in ASCII/ANSI and then switch on the fly to Hexadecimal or PPP for debugging.
The screen allows cut, copy and paste operations, but only the copy function is meaningful. Highlight a message on screen with the mouse, then press Ctrl-C to copy the highlighted text to the clipboard. You can paste the clipboard contents into the send message box for further manipulation, or into another application for analysis. If an area on screen is highlighted, the Ctrl-X, Ctrl-C and Ctrl-V key presses will operate as clipboard commands and will not be transmitted on the serial port. If you cut from or paste to the screen, it will modify the display, but the information will not be transmitted, so only the copy command is meaningful.
Once your system under test creates the packet frames correctly, you can switch to HDLC, PPP or ICNI View. In these modes, WinHexCom will parse the data stream and attempt to extract messages from it and HDLC/PPP stuffing will be removed to yield plain messages. Only messages with reasonably valid frames will be displayed. WinHexCom does not verify the message checksums. Message parsing reduces the amount of screen clutter dramatically and will allow you to debug system operation, without seeing all the inter packet garbage.
In ANSI mode, all valid ANSI escape codes will be suppressed. Some ANSI commands will be executed; mainly the ones for cursor movement and screen/line editing. The ANSI emulation is not perfect, but you should get a reasonably formatted screen when connected to a target with ANSI terminal output.
A PPP message with time stamp looks like this:
Tx1 16746 7E 7D 51 22 33 44 55 66 77 88 99 99 14 7E
Rx1 16746 7E 11 22 33 44 55 66 77 88 99 99 14
Note that on the received message, the PPP Escape code 7DH is removed and the next byte 51H is XORed with 40H, to restore it to its plain state of 11H. Any trailing flags are also suppressed, since inter message gaps may be filled with flag characters.
The X-modem protocol operates in the standard mode with 128 byte packets and a modulo two checksum, as originally created by Ward Christensen in his ancient Modem2 program circa 1979, some time before the dinosaurs; as well as the slightly more recent extentions for CRC16 error detection and 1 kilobyte packets, a.k.a. Y-Modem protocol.
X-modem provides a simple, but effective file transfer mechanism, with limited error detection and recovery and will efficiently send or receive a file to equipment under test. It does not matter whether the receive or transmit sides are started first, as long as you start both sides within the usual 10 second limit. A simple way to synchronize the transfer, is to wait in the file selection dialogue and only press the file dialogue Open button once both the transmit and receive sides are ready. The Abort button can be used to terminate the transfer when something goes wrong.
The Binary Dump is not really a protocol at all. In this mode, WinHexCom simply sends or receives the file as is, in 8 bit binary mode. During transmit, the file dump will continue until the end of file is reached, but when a file is received, there is no telling when to stop. The user therefore needs to use the Abort button when the transfer activity ended, to close the received file. There is also a 15 second timeout, which will terminate the transfer after 15 seconds of inactivity, so it is OK to start a transfer, then go and get some coffee...
The protocol analyzer function requires the use of two serial ports simultaneously. The file transfer function does however only use a single port. The file transfer function will therefore use the port selected as the Send port. The protocol analyzer function is inhibited during file transfers.
ANSI (VT100) terminal emulation is still under development, although basic functions do work for cursor movement, page up and down, clear line, clear screen and so on. What is still a bit flaky, is the ability to position the cursor to exact X-Y co-ordinates. While an ANSI screen is only 25 lines high, WinHexCom will allow an 'infinite' screen length, by scrolling in increments of 25 lines, thereby creating multiple pages. The X-Y positioning commands will always operate in the page where the caret is. It is possible to move the caret by clicking in the screen, which will of course muddle up the co-ordination between where the target thought the cursor was and where it now is, until the next clear screen or goto-xy command is executed. These differences between a PC screen and the original DEC terminals will never be fully resolved, but is not much of a problem in practice. If you moved the cursor to another spot - well, you know you did that, so you would expect things to be funny after. In version 3.00, these functions are largely working and the ANSI mode is useable, but there are still a few strange things happening on the screen which we would like to resolve.
The purpose of WinHexCom is first of all, to be an effective protocol analyzer. To this end, WinHexCom can operate two serial ports simultaneously. An interactive terminal emulator however requires that the display of only one port be allowed, as the data from a second port will upset the full screen information display. The ANSI terminal therefore use the port selected as the Send port and should disable the other port while the ANSI session is in effect. In version 3, both serial ports still remain active and the ANSI terminal emulation as a whole is still rather unreliable.
If you want to use a communications port for another purpose, simply run that program first, then launch WinHexCom, which will then grey out the status box of the port which is already in use. Alternatively, set the second port on WinHexCom to a non-existent port, to allow the other application to use one of the serial ports.
For the rare occation where you want to monitor 4 or more communications
ports, you can run multiple instances of WinHexCom. Each instance
can handle 2 comm ports, but to do so successfully, you need a fast PC.
A PC has either a 25 or a 9 pin serial connector. Here is a list of the interesting pins on these connectors. Ignore the other pins - leave them unconnected. 9-pin Connector (Male at PC) 25-pin Connector ---------------------------------------------------------------------- 1 CD Carrier Detect (Its life Jim...) 8 2 RX Receive (...hlab ,hlaB) 3 3 TX Transmit (Blah, blah...) 2 4 DTR Data Terminal Ready (Local PC ready) 20 5 GND Ground - common (Terra firma) 7 6 DSR Data Set Ready (Remote equipment ready) 6 7 RTS Request to Send (I beg yours?) 4 8 CTS Clear to Send (Shoot!) 5 |
A general purpose loopback connector can be made as in figure 2 and is a handy test tool.
Loopback Connector Connect the following pins together: ------------------------------------------------------------------------------ RTS to CTS Ensures that CTS is always true DTR to both of DSR and CD Ensures that DSR and CD are always true RX to TX Loop back data so we can talk to ourselves A loop-back connector like this is always very handy, so you can just as well make a good job of it and screw on a backshell and mark it as a loop-back test connector for future reference. |
Finally, a RS232 Null Modem cable can be made as in figure 3 and is
probably the most used cable, so it is worth doing a very good job.
A NULL Modem Cable ------------------ There is an almost infinite number of ways to make such a cable. The simplest method is a variation of the loopback plug. Connect the following pins together on each connector: RTS to CTS DTR to both CD and DSR Then run 3 wires (2 or 3 meters, whatever is convenient to reach the other PC) between the two connectors for your data connection: GND to GND RX to TX TX to RX |
You should be able to compile the source with a number of compilers
since the code is written in ANSI C. It will however be easier to
compile it with the compiler system LCC-Win32 of Jacob Navia, which can
be downloaded and licenced (a minimal fee) from here:
http://www.cs.virginia.edu/~lcc-win32/
For your convenience, a recent version of LCC-Win32 is on the CD, in the directory lcc_zip. To install, simply click on all the files one by one. This compiler is very small, fast and reliable. Go to the web site above for licencing information and the latest version.
A LCC-Win32 project file winhexcom.prj is provided. You can import this file with Wedit, the IDE of LCC-Win32 and make the project. Note that there are file dependencies in the project file: "ProjectPath f:\lcc_work\WinHexCom". You have to edit these dependencies to correspond to your setup before you can import it successfully.
Before embarking on an enhancement of WinHexCom, it is advisable that you first try to compile the code as is, to ensure that your setup works properly.
Source Documentation is available in HTML format in the html directory. The main page is index.html.
Unlimited Enterprise software licence: US $200.
An Enterprise licence includes the C source code.
The licence entitles the user to one year of free updates, as from the day of registration.
Dual port ISA bus RS422/485 adapter: US $120.
RS232 adapters are common things and available off the shelf almost anywhere.
Have fun!
Herman
Copyright © 2000, Aerospace Software Ltd., Calgary, Canada