ICTester Manual

ICTester is written in C++/Qt, so it's portable and can be run both in Windows and Linux environment. All configuration is stored in 2 files (.ictestrc.ini and .icpower.rc) in .config subdirectory of user's home directory. It should be compiled on Qt5.x systems as 4.x is not used since 2016.

Table of contents

1. Getting to work
2. Main Window
3. Typical workflow
   
4. Configuration
5. Sheet editor
6. Low-level interface test
7. ROM reading tool
8. IC identifying tool
   
9. GUI program parameters
   
10. Command-line version
11. File structure
12. Console tools: ROM dump
13. Console tools: S/RAM test
14. Supported ROM/PROM/EPROM list
    

        Supported IC list and where to find test sheets

Quick jump:
    Error codes
    Pin ignoring
    Intepreting failed test results

Getting to work

The first thing you should do after installation or compiling (ICTester requires Qt libraries and QtSerialPort library, if you want to build it from sources) is to create your own directory for test sheets. Test sheets (MOD files) are files which store test procedures for circuits. You can use test sheets from the original version of IC Tester's software.
Then it's convenient to add romreader.ini file to this directory, because it contains all ROM chips definitions. This software can read ROM chip contents.
To get original test sheet files, you have to download full installation (MSI) version of Windows software (e.g. from here) and install it. In Linux you have to install the software with Wine (use Wine's msiexec) and take Datasheets from their directory. The original software doesn't work with Wine 1.6.2.
I recommend to create simple directory structure for different families of circuits (74xx logic, 40xx logic etc.) as it helps a lot. Then you can put test sheet files in your directory and run the program.

Main Window

The program's main window (shown below) consists of several parts.

• Toolbar and menu bar - used as in most applications.
• IC Preview - in the top-left part of window, shows IC being tested. If a !!! is displayed near pin, it means that error occurred while comparing to this pin.
• Test control panel - below IC preview - allows to specify test parameters and start/stop tests.
• Test log - right side of window - contains information about test steps.
• Status bar - contains name and description of currently loaded test sheet as well as information about ignored pins.
  

Typical workflow

The first thing to do is to load test sheet for verified circuit. To do it, press the first button in toolbar or select item from File menu. File menu keeps list of 10 recently used test sheets. After you click Open icon, Open dialog pops up:

The first thing to do here is to select your test sheets directory - it will be stored with program's configuration so you won't have to click through all directories again. Now you can select test sheet. You can quickly find the sheet by typing part of its name/description in text box above the list, you can activate the search box by clicking it or pressing / key. After you click a sheet, you'll see its preview. Confirm test sheet selection by clicking OK.

Then you have to configure test parameters, do it by inspecting left-bottom part of main window. The options are explained below:

• Start - Starts test.
• Stop - Allows to stop test any time.
• Update pins - if checked, IC visualization is updated in real time during test.
• Update log - if checked, log is updated in real time during test. During long test it may be beneficial to disable updating-related options to speed the test up. If they're disabled, Test Statistics part should be used to check is test passed or not.
• Read after send - This option performs automatic reading of IC's pins every time its inputs are changed, the result is shown in IC drawing in the main window. Together with Single Step option it may be useful in understanding chip's principle of operation or in debugging test sheets.
• Single/Repeat Test - If Single is checked, test is performed once. If Repeat, test is performed in loop. Maximum amount of test runs in loop is controlled by max rep. value
• Abort on error - If checked, the program will abort test if there was an error. If not checked, the test run is still considered as failed in Test statistics, but it's performed to the end (or end of series is Repeat is selected).
• Single step - If checked, the program stops after each test script's step and waits for user to confirm a window. Useful for debugging.
• Test Statistics panel - shows number of test passes performed, current test step, number of successful and failed passes.

After you've configured test parameters, you can hit Start button. This doesn't start the test yet. Instead, power requirements window is displayed:

Then you must configure your tester according to drawing and after putting IC in socket hit OK to start the test. Any time you can display current sheet's power configuration by pressing Show Power Requirements button in toolbar.

A successful test run is shown below:

As we can see from log, device (tester) was restarted, configured, power has been turned on and IC passed all checks. Notice Test Statistics counters state.

Now let's look at failed test window:

In this picture the test has failed. We can see that:
    - Test failed on pins 6 and 9. Error in pin 9 is marked "!!!", which means that it failed the test.
    - Error in pin 6 is marked "..." which means that there was an error, but pin 6 is set as ignored (pin is marked with "X-").
    - Pins marked "*"  are power pins.
    - Pins marked with "_" are GND pins.
    - Pins not marked are NC.

Pin ignoring can be configured from Actions menu or (since version 20150926) from toolbar button. You can program some pins (enter them as comma-separated list after selecting "Ignoring pins") not to be included in test. This is useful if you have bad IC, but you are using only good pins and want to verify that they are good in a full test. Ignored pins list is cleared every IC model loaded or if you leave blank field in "Ignoring pins" window.

Testing in series (new in version 20190702) can be invoked from Actions menu or using a toolbar button. This type of test asks for the power configuration once, performs test and waits for pressing Return key in the pop-up window. The chip can be replaced with another one of the same type and pressing Return will test it. This test will not be interrupted entirely by "Abort on error" option". To interrupt, press Esc or Cancel in the pop-up window and the result will be shown on log. This option is useful when it is needed to test a lot of chips of the same type.

If you get a device error like this:

it means that there was a problem. In most cases the problem is:

• Power to tester - is not connected
• Tester is not connected properly (try to "pass-through" check the port by removing PIC from tester, shorting two long wires in PCB, then power it on and try to get echo on serial terminal - it's described in "faultfinding.txt" file in original tester's software directory)
• Configuration of serial port is wrong (or you have problems with permissions in your operating system)
• In rare cases it may just happen if tester is doing something other and Reset is used to interrupt. In such situation, after unsuccessful reset the tester is still "frozen" and it requires second, successful reset.
  

Error codes are following:

• 0 - Operation completed without error
• -1 - Port is not opened - selected serial port does not exist, permissions problem or port is used by another application.
• -2 - Device is not present - Tester did not responded in significant amount of time (default 1sec)
• -3 - Unknown response from tester - is it working properly? Aren't you trying to test ICs having configured port with e.g. barcode scanner connected there? :)
• -4 - Program's internal error in data form.

If your tester hanged with power on, you can always force its reset by clicking the reset icon in a toolbar - the one with opened switch.

Configuration

Configuration window can be called from Tools menu or toolbar icon. Let's see the first configuration tab:

This is quite straightforward. In this window you can change communication port to which tester is connected. And in most cases only this setting has to be changed. Modification of baud rate requires modification of tester itself, so it's safe to leave it at default 19200, change to 57600 if your tester has 57600 jumper installed. Timeout value 1000 is suitable for most computers. If your computer is so fast that during long tests tester "drops" some commands, you can slightly increase Delay every step value, but this should never happen in modern (>2005) hardware and in many cases 0 will work.
In this tab you can also point your default language. By default, the program is started in your operating system's language (or English if not accessible). This is "AUTO" mode. Using a "Program language" box you can force specific language to be used for all next program starts.
You can also disable clearing log before each test. Sometimes having multiple test results one after another in a single log may misinform user, but sometimes it may be needed.

This tab is very important. As you've seen by looking at IC tester hardware, Tester's board has 4 DIP switches connected to power or ground, but it can support more with user settings. For example if you check many chips in 24-pin casings, and they need power connected to pin 24, you can use 5th DIP to connect power to pin 24. This window allows to define these additional switches and they're taken to account when suggesting you power configuration before test. Double-click on a selected DIP switch function to change what is connected to it: Power (Vcc) or ground (GND). There may be "empty" DIP switch too, it's just disconnected so it's only drawn as present, but not used. Then you have to specify socket's pin which is connected with this DIP switch. You can always revert to default setting by pressing Set defaults button.

WARNING! - bad configuration of DIP switches in program may produce misleading results in power configurations provided by it. This may cause even damage of tester or IC tested!. It is important to double-check are settings entered here reflecting IC tester wiring!

Building your own sheet

You can build your own test sheet to test new ICs. The test sheet is a file which consists of two parts:
     - IC data: Name, description, pins count, pins I/O/Power/Ground/NC role and their descriptions,
     - IC test script: Information how the chip should be verified.

First, open any sheet from directory in which you want your new sheet to be located. This tells the active directory with test sheets.
Then press the Create new test sheet button in a toolbar. Program will ask you for new sheet's name and then will go to editor. You can call editor with any sheet by pressing Edit current test sheet button.

The editor consists of two tabs. In the first one you specify inputs and outputs of circuit and it should be filled first. Notice that Changing pin number erases the test script so don't make mistake here.

If you change sheet's name, the file name changes too. If you've changed it, program will ask do you want to preserve file with old name.
Change pin functions by double-clicking on Usage cell. You may fill Tag with pin name to make identification easier. In some operating systems pressing Return will automatically move editing to the next pin. After specifying IC details you have to program a test script in the second tab.

This is a script editor. Usually most scripts start with Reset-5V ON commands. If your IC has pins which are both inputs and outputs, you can re-configure I/O during script execution. High-Low-Doesn't matter (X) states are modified by double-clicking specified cell. The tag of the pin is shown in a tooltip near cursor (like in a screenshot) and in the bottom, between delete and Check buttons to make development faster.
You can generate specific number of pulses (state toggles) on selected pin using CLK button. Then you are asked which pin to use and how many toggles do you want. All other pins are kept in their last state. This is useful in testing counter chips. Do not put too big values as you may later need to delete them by hand.

Another important thing is the Comment button (new in 20191028). It inserts comment which can be used to mark important places in sheet and to describe what particular test does. However, there are some important information about comments in these scripts:
1. A typical comment is inert - it is not counted as script's step, it is not visible during tests. It can be seen and edited only in sheet editor.
2. If comment text ends with ; - it's not inert anymore. This comment is part of script now and it's seen that it got a number in a script. The text of this comment will be shown in log window during tests. This way you can inform user that e.g. a long clocking sequence will occur.
3. Comments may not be compatible with original version of ICTester - this Windows 9x one. It may even remove them from test sheets edited.

To briefly check some issues you can use "Check" button. 

A good testing script should cover the following issues:

• All output pins must be checked - are both states present on them.
• All input pins must be checked - does IC react on their change.
• All I/O pins must be checked in both directions by reconfiguration.

This button performs simple checks, and warnings are not critical, but may be helpful identifying is test complete. These tests are following:

• Are there Power and Ground pins. If there are more power/ground pins than one pair, program will warn too,
• Are there both inputs and outputs?
• Do all pins have the tag (name)?
• Does test start with Reset-Power On commands?
• Are all outputs verified for high and low state?
• Are all inputs verified with high/low state?
• Does test end with reading?
  

This checking doesn't modify script nor IC design.

Low level interface test

To check are all pins working, the software has a low level test which allows to "light up" a pin in socket. The test window is shown below:

Because PIC's lines use pull-up resistors connected with switchable +5V, it is needed to take it into account during testing with logic probe. To avoid short-circuits, remember to switch all DIP switches OFF and remove any wire links before connecting with device.

To get information about tester firmware, use Identify device command in Tools menu.

ROM reading tool

WARNING: This manual is for ROM reading module introduced in version 20150720. Earlier versions are different

This is the newest version of ROM Dumper which has significant improvements. First, it doesn't need to be re-built to add a new chip - user may just write a new chip definition in GUI or text editor. By programming, only new reading algorithms are added.
Second, this tool now allows to preform advanced read tests of ROM. This won't test the device's speed, as IC tester is quite slow, but will certainly test the read stability and access lines. 

The first time you run ROM dumper, You have to select the INI file with ROM definitions. I recommend placing this file near Your IC test sheets, as you may need to modify it, e.g. add reading procedure to ROM you want to read. The file name will be remembered in main program's INI file, and You will be prompted for it only when it won't be accessible. Any time, you can change default INI using "Load INI" button. Newly opened definitions file will be remembered.

The software consists of 3 tabs. The first one is well known from previous versions and is used to read ROM contents to buffer, save buffer to disk, load it or clear it. You can also verify contents against buffer. The only difference between previous version is that the verification stops if any error has been found instead of completely reading chip, which makes things faster. 

Always the first step is to select the proper circuit from the drop-down list. For list of supported circuits read this chapter. To read circuit, press Read button. Program will ask you to set proper power setting and will read the circuit. The contents will be displayed in buffer in hexadecimal form.
To verify reading use Verify button. The chip will be read with comparing with buffer. Also you can use this option to compare chip with file on disk - just Load the file from disk and Verify your chip with it. The first different byte will stop reading and the byte will be displayed in the status text.
After Reading, you can Save your buffer to disk.

The advanced reading tests are present in the second tab. This tab is used for advanced validating ROM reading against current buffer contents, testing data and enable lines. It should not be used for checking speed, because IC Tester is not very fast as reader (comparing to devices as fast as e.g. Willem 3.5 programmer). You can set test repeats for all tests here - if something fails the tests will stop. There are the following reading modes:
- Read forward - is a normal verification, like the one in previous tab.
- Read backward - reads ROM contents backwards, evaluating against buffer.
- Random Read - reads ROM using random addresses.
- Test each word at least ... times - terminates random read test (or goes to the next repeat) when all words have been read at least specified number of times.
- Override waiting - allows to override WAIT parameter in chip definition. -1 turns it off.
ADVANCED DESCRIPTION: WAIT parameters in ROM model determine how long (in ms) the program should wait between stuffing the address to chip and reading data, in some chips also between stuffing the address and enabling chip (some chips need to be disabled for addressing and then enabled). Default value is 2, and is good in most cases. Lower values make the chip to be read faster (which is good for reliability tests), but tester may not handle commands given so quickly. We usually do not overspeed the chip as the tester is the bottleneck here.
- Power cycle between repeats - This is advanced thing which reinitializes chip (turning power off and on) every specified number of words read, simulating turning power on and off.
- Random power cycling - Randomly turns power off and on. Some old chips, especially soviet PROMs in brown cases like to fail right after powering up. This test should reveal problems.

For NORMAL reading algorithm, there are also two additional tests. Both tests require at least one chip reading and this initial reading can be skipped by using checkbox below (buffer contents are used). Both of these tests are not conclusive, e.g. they don't indicate always that the chip is bad and their results must be analysed with knowledge about chip and its usage.
Data lines test - First, the chip is read to buffer (or buffer is used). Then all words are checked if all bits change. If bits are "locked" in 1 or 0, it is indicated. Unused lines in chips may be just not programmed, or line may be bad.
"Enable" lines test - The chip is read to buffer or buffer contents are used. Then one of ENABLE pins is toggled to the opposite state and chip is verified. If the result is different, the pin "passed" the test. If the reading is the same, pin is taken as "constant". This operation is performed for every pin defined as "ENABLE" or control pin. It may indicate damaged ENABLE lines, but in many PROMs there are lines, e.g. for programming, which should be kept e.g. high, but it is not compulsory. This pin will be indicated in the end of tests with a good chip. 

The third tab is a model editor. It allows user to modify or add ROM chip definitions to INI file. After applying ("Apply changes" button) modifications, modified version is used, but to be re-used after closing ROM dumper window, it must be saved ("Save As..." button) to INI file.
Right side is quite obvious, allows to add, remove and order items. It is possible to add model ("+" button) or "delimiter" ("-[+]-" button), which has name always starting with a dash. If there is no dash in comment's name, program will add one when applying. These delimiters are used to split ROM listings to nice sections for better navigation.
Remember to apply Your changes after changing model settings in the editor.
Currently only a typical address-data algorithm called NORMAL is implemented, so this "NORMAL" is just indicating it.

The picture below shows how the definition is made from datasheet. Then new definition should be verified experimentally, especially enable/addressing states, which in some chips are not needed:

IC identification tool

WARNING!
This is a highly experimental tool which may even damage tester or IC identified. This tester cannot detect Hi-Z (high impedance) state, so testing is made around test sheets. Although quite safe, some fragile ICs may not survive momentary current draw. Use it carefully and as fast as possible. Generally, if a chip is easy to damage with TTL pulser, don't use it in identification.
To skip warning on start, use any text editor to open Your ~/.config/.ictestrc.ini (Linux) or ictestrc.ini (Windows) and add

warnUnstable=0

at the end of [Test] section.

The tool can be launched from menu or toolbar button. This tool is made to help identify chips with worn off markings. On first start-up, you have to specify a directory with test sheets. This directory is recursively searched for test sheets to test and a list is shown in right-side table. You can always change it using "..." button. The "New" button reloads sheets and makes program ready for another detection.
First, it is needed to input pin number and their power requirements. It can be easily deduced from PCB how the chip is powered up. When you select pin number, the list is filtered again and default (for 90% of 74xx circuits) power settings are entered automatically.
After entering power pins (in comma-separated list, remember that /CE and /OE pins, sometimes connected to ground, are functional pins, not GND) and clicking Start two things happen:
1. List is filtered again, to make list of chips with power according to specification. If no chips are left after this filtering, the program stops here and displays message.
2. If there are chips with correct number of pins and power specification, program asks user to prepare tester, then chip is tested against all items in the list. You can see the testing in status bar and by blinking power LED in tester.
By default, when test passes, identification program stops and type of passed IC is shown in the status bar. You can force test of all IC definitions by unchecking "Stop on first passed IC" checkbox.
Below you can see the program after successful 8286 identification.

GUI program parameters

GUI program can be started with following command-line parameters:

• -reset - silently resets device and exits
• -test  - launches low-level diagnostic tool
• -romread - launches RAM/ROM.EPROM reader module
• "MOD file name" - Loads chosen test sheet and awaits for user actions
  

Command line version

There is a command-line tool which has basic tests and diagnostic capabilities. The usage is following:
ictestcon ttySx x circuit.mod
Where:

• ttySX is a serial port name. It can be separated with : and baud rate can be given (e.g. /dev/ttyS0:57600), if not, 19200 is used. There can be another value after second : (e.g. COM1:57600:3000) which is a timeout value, default is 1000.
  
• circuit.mod is a path and name of test sheet file
• x is a command.

Available commands:

• t - normal test, asks user to configure tester and press Return.
• l - As above, but after pressing Return test loops infinitely (or until error/Ctrl-C).
• n - one pass, totally non-interactive, doesn't ask user. In such test it's important to configure tester first, as misconfiguration of power may damage chip.
• r - resets the tester turning power off - it you've hit ctrl-C in test and power left on.
• c - Low-level interface test, bit-by-bit.

Files structures

 - ictestrc.ini is quite self-explanatory, the only thing is with colors - they're stored separately, Red-Green-Blue, value after value.
 - icpower.rc consists of set of lines, each line has 3 comma-separated values. The first value is DIP switch number. Second - to which is connected (0 - ground, 1 - power, 2 - nothing), third - DIP socket pin which is connected to the other side of switch.

WARNING: From version 20190702 these files reside in ~/.config, not in ~ as previously. The program, both command-line and GUI, will copy the files to new locations and use these but will not delete the original files in case you want to use an older version. It is up to the user to decide should old files be kept (when older version of program is used in parallel) or not.

TEST SHEET (MOD FILE) FORMAT:
The format is the same as in original EPE IC tester. CR/LF (line endings) are the same in Linux version, Windows-like.
If a line starts with # - it's a comment. Skipped during read. Empty lines are skipped too.
After ignoring comments and blank lines, we have a pure script file.
Now it's needed to parse it, each line has its meaning, line order is significant here.
1. IC Model name (e.g.. 7404)
2. IC description (e.g.. Quad NAND gate)
3. Number of pins in package  (called later NumOfPins)
4. Pin for + power .
5. Pin for GND  - if there are more GND/power pins original software gets lost, my software proposes wire-based solution.
Starting from line 6 there are NumOfPins lines for each pin, they look like: a,b,c: (3 fields comma separated):
  - a -  Pin number.
  - b -  Pin description as string
  - c - pin usage
    - 0 - Logic i/p
    - 1 - Logic o/p
    - 2 - Universal i/o reconfigurable later? - not fully implemented.
    - 3 - GND
    - 4 - Vcc
    - 5 - NC
 Then test script lines come until end of file, they look like a,bcdefghijklmnopqrstuvwxyz
  - a - line number
  - b - command
    - 0 - Reset device (Vcc off)
    - 1 - Vcc on
    - 2 - Configure pins.
          This operation is usually not present in start of script, but generated from pin configuration.
    - 3 - Send state to pins - zero should be sent to o/p pins.
    - 4 - Read state from pins
  - c..z - directive arguments:
    - 0 - logic 0 , or input in command 2
    - 1 - logic 1 , or output in command 2
    - X - logic "doesn't matter" in testing or power pins in setup 

ROM READER (INI) FILE FORMAT
The file is in fact Windows-like INI file containing serially-written ROM definitions. All pins are relatively to the chip, not socket, e.g. 14-pin chip's pin 7 is socket's pin 12, but it is described as just pin 7. In the top there is always a GENERAL section which looks like:

[GENERAL]
MODIFIED=20150709021935

It contains last save date, in YYYYMMDDhhmmss format.

Next, ROM definitions are written one after other. There must be always at least one empty line between definitions.
If there is an empty section starting with "-" like:

[--- EPROMs ---]

It means that is it is a category. The categories are for better ordering chip models and are not selectable.
Normal chip model looks like this:

[2716]
DESCRIPTION=EPROM, also K573RF2
PINS=24
GROUND=12
POWER=24
BITS=8
WORDS=2048
METHOD=NORMAL
ADDRESS=8,7,6,5,4,3,2,1,23,22,19
DATA=9,10,11,13,14,15,16,17
ENABLE_PINS=18,20,21
ENABLE_ON=001
ENABLE_OFF=011
WAIT_ENABLE=2
WAIT_READ=2

The section header (always in square brackets) contains chip name. Next variables are:

• DESCRIPTION - chip description,
• PINS - pins count,
• GROUND - ground pins list, comma-separated,
• POWER - Vcc pins list, comma-separated,
• BITS - number of bits in word, maximum 8,
  
• WORDS - number of words in chip,
• METHOD - reading method. Currently (2015.07) only NORMAL is implemented.

NORMAL method has the following parameters:

• ADDRESS - comma-separated list of Address lines pins, going A0, A1, A2 ...
• DATA - comma-separated list of data lines pins, going D0, D1, D2 ...
• ENABLE_PINS - comma-separated list of control and enable lines pins. Order is unimportant.
• ENABLE_ON - accepts only 0s and 1s. It is a digital state on ENABLE_PINS which makes the chip output data.
• ENABLE_OFF - as above, but it's state in which the chip can receive address. If these two are the same, chip is addressed and read with the same enable lines state.
• WAIT_ENABLE - time in ms between address stuffing and enabling chip.
• WAIT_READ - time in ms between enabling chip and reading data. If ENABLE_ON==ENABLE_OFF only WAIT_READ is used.

After each definition at least one blank line must be present.

ROM dump console tool

The ROM dump tool can read he same ROMs that GUI, using INI files as definition sources.
The usage is:

    icromread FILE.INI [r/s/d] port model FILE.BIN
Where:

FILE.INI - is a path to INI file with ROM definitions.
[r/s/d] is parameter:
    r - reads ROM content to file,
    s - as above, but doesn't prompt for power requirements,
    d - displays only contents of INI file. Doesn't need port/model/file parameters,
    v - verifies ROM contents against FILE,
    f - as above, but doesn't prompt for power requirements.
port - is a serial port for tester. It can be separated with : and baud rate can be given (e.g. /dev/ttyS0:57600), if not, 19200 is used.
FILE.BIN is the ROM dump file to write to or compare with.

S-RAM test console tool

The following S-RAM test programs are enclosed: 2114test, 2102test, 6810test, 6116test and 93415test, for testing specified S-RAM chips. Running of them is simple:

Supported ROM/PROM/EPROM circuits

MCbx, 2014,15-19.