













|
IC Tester HELP - Database section Test data
files
There are three types of files which are used with ictester program. All files
are textual and you can edit it with text editor. In all files #
character at beginning of line is used to comment entire line.
First type is link file and have identical suffix like one of other two
file types. Main purpose is to redirect reading to another file.
For example, there's test file for 7400 ICs, but you can with that file test
7403, 7437, etc., why? Because IC logic and pinouts are the same, only
difference is on some upgrades which this IC Tester device can't test anyway.
So that test file don't have to be copied in several copies and took
additional space on disk, instead of that there's this link file which is
small and it can redirected program to another file.
Structure of link file:
- line: Information to program which type of file is it that it knows how to
read it.
- line: Starts with keyword Information: after what comes text which
will be wrote when program reads file.
- line: Contain location of redirected file, so that program knows where is
it.
You can look in database directory /usr/local/share/ictester/data (default on
Linux and Minix) or C:\ICTESTER\DATA (default on dos) for 7403.adf or
4016.ddf file to see how it looks.
Second type is dump file and have .ddf suffix.
This is dump file which is generated from program, but you can edit it like
others, just make sure that next lines are in place:
- line: Information to program which is file type, so that it knows how to
read it.
- line: Description of dumped ICs, like part number and comments.
- line: Number of pins, location of +5 V pin and GND pin at dumped IC.
- line: First and last name who is author of this dump file.
- line: E-mail address of author.
Next lines: Contains data which will be set and read from device. This data
lines must be in form that first 16 characters are for setting and next 16
characters what should be read from test socket at device.
You can with -d option generate dump file and take a look in it to see
how it looks.
You can use -c option to check if data from this file match with data
from tested IC, but this doesn't work with complex ICs like counters,
bistables, shifting registers, etc.
Check for details in Program - ictester section under -c
option.
Third type is analyze file and have .adf suffix.
This is real test file, with it you can test if IC is correct and if it's not
where's the problem and how to use this IC.
For standard testing you can use -r option to read status and -w
option to set data on test socket. But if you want test more ICs on the same
principle, you don't have to do it manually with r and w options,
you can write those testing steps in script, which is this analyze file.
Make it easy to you, there are few rules which you may find very interesting.
First line must be information to program which type of file is, so that it
knows how to read it.
Next lines you can wrote with listed actions:
Each action have first letter and ':' character, after that you write
parameters for that action.
NOTE: when you use action make sure that all parameters for it is write in one
line and that line can't be longer that 255 characters (including action
letter).
- A: - Entry for author name and (or) e-mail address, you can
multiply this action and write unlimited lines with it.
Only limitation is
that total characters wrote under all entries mustn't be larger than 65025.
- M: - Last modify date. Here you place last date when you modify this
file, so that other if using it, know which ones is newer. It should be only
one action of this type in file. The date must be formatted as:
YYYY/MM/DD-HH:MM-ZONE, e.q.: 2001/03/29-16:58-UTC. Please use this
format because program checks this date to determine which file is newer.
- D: - Description of tested IC, in here writes what is type of tested
IC on which you use this file. E.q.: 4 x NAND gates with 2 inputs.
It should be only one action of this type in file and you can write maximum 255
characters.
- T: - Title of ICs which this test works and it's tested. In here you
write prefix and root number of tested ICs, so that others may know on which
manufacturers this works. I know that must work on all, but there are some
exceptions.
You can write unlimited lines of that action, only be careful
that total number of all characters from all lines of that action not exceeds
65025.
- N: - Real name of tested IC, here you put actual name of IC for
which this test file works. Eq.:SN 7400 or CD 4011. It should be
only one action with maximum of 255 characters in line.
All actions which are write above must be written before any actions which
will be described next. Also try to write it in orders which are listed above,
because program display information from actions as it reads it.
When you want import this file into database, all comments what you type before
any W:, R:, E: or ?: actions will be erased. If you do not write comment
before this actions as:######### Test part from here #############, all
comments will be ignored and not included in database.
- W: - Set power on test socket, input entry identical like in
'-w' option for program. So you write this action letter and after that
16 characters which are used to set data at exact pin. E.q.:
W: ======0========1 for powering up with +5V on pin 16 and GND at pin
7 and you can using this action unlimited times, like
W: =100===0=======1 W: =010===0=======1
W: =110===0=======1 W: =001===0=======1
W: =101===0=======1 W: =011===0=======1
W: =111===0=======1 three bit binary count at pins 2, 3 and 4, with
power on of +5 V on pin 16 and GND at pin 8.
All rules for characters are the same like in -w program option.
1 - sets +5 volts on pin.
0 - sets 0 volts (GND) on pin.
= - sets NC (not connected) on pin.
When using this option, always on output pins set '=' character
(not connected (NC)), on that way you will secure tested IC from short circuit
and that's the only way how you can get right information.
- R: - Read data from test socket, if read data don't match with one
you write then test fails.
This action is usually used after W: action, and its check what status
is on test socket. You have some rules, which can help you to analyze output
from device:
1 - on that pin is +5 volts or is NC (not connected).
0 - on that pin is 0 volts (GND).
= - use this character to ignore reading from that pin.
You can using this action unlimited times, usually it's used with E:
action.
Writing parameter is equal to one from W: action, only difference is in
differ character meaning. E.q:
W: ================ - you set to all pins NC
R: 1111111111111111 - read status at test socket. All pins must be set
to +5V or NC or there's error.
NOTE: IC Tester device can't tell difference between +5V and Not Connected
state.
W: =======0=======1 - set +5V on pin 16 and 0V (GND) at pin 8
R: 1======0=======1 - now check if there is +5V on pin 16 and GND at pin
8, also test only if on pin 1 is +5V or NC.
R: =0=====0======== - now check if there is GND only at pin 8 and pin 2,
if one of last two reading don't match with data there's error.
- E: - Error report, write what's wrong with tested IC.
Use this action after one or more R: actions to display error. If
message is longer that one line or more than 255 letters, you can write rest of
it in new E: action which follows.
Here is example how you can use it:
W: ================
R: 1111111111111111
E: Detecting power on some pins and there shouldn't be any!
E: Use -t option and do test IC Tester device to make sure that's working ok.
In this example, first is set NC to all pins, next we read status and checking
that output is all with +5V or NC (in this case NC).
If output wasn't what we expected then there's some error, now program will
read information under E: action and wrote it.
Program will wrote all E: actions until it read first other action.
Of course you do not have to put this action after every R: action, see
next example:
W: 00====0========1
R: 001===011======1
W: 01====0========1
R: 011===011======1
W: 10====0========1
R: 101===011======1
W: 11====0========1
R: 110===011======1
E: There is problem with gate 1 at output pin 3, GATE 1 DON'T WORK!
In this example we set +5V on pin 16, GND at pins 1, 2 and 7.
After that we test if on pins 1, 2 and 7 are GND and on pin 16 +5V, in this
case we test only first gate of IC SN7400 which have 14 pins.
All other gates we will ignore from testing, setting and reading.
So pins 8 and 9 are not occupied and there should be NC, on pin 3 is output
from first gate and IC logic NOT AND tell us that on output must be +5V.
In that pattern we do 2 bit binary count on inputs of first gate (pins 1 and 2)
and check if output data match to one what we expected.
If in all of this tests are one or more failure then program will wrote message
under E: action.
This action will be used if there is error (not match under R action) and it
will be reset after use, so if on next test is another failure then it will be
used again. All E: actions in between if there's no error will not be
used.
- ?: - If there was error, write message, and ask for continue.
This action works as E: action but with one difference, it asks if you
want to continue testing after any error.
Look this example:
W: ================
R: 1111111111111111
E: Detecting power on some pins and there shouldn't be any!
E: Use -t option and do test IC Tester device to make sure that's working ok.
?: I advise you to check if device working properly, continue testing?
Here is testing if after we set NC to all pins, status is identical on all
of it. If that's not the case then it's possible that device not working
properly. That is serious problem, because if you continue test, you could do
damage to tested IC and to IC Tester device itself.
So we used here ?: action to make possible break from testing.
Also you can use this action if there are a lot of errors to abort testing,
because there will be errors and when you continue.
- P: - Pause for number of milliseconds (1000 msec = 1 sec).
This action is used when you need to delay execution of test file for some time.
E.q.: P: 5000 - delay execution for half of second.
Action is included here because it's used with test files for addons. When you
tests standard logic ICs it's not needed, because IC Tester device isn't that
fast that you have to use it.
You can look in database directory /usr/local/share/ictester/data (default on
Linux and Minix) or C:\ICTESTER\DATA (default on dos) for 7400.adf file
to see how it looks.
When you write test file take this advice for writing test part:
- Set to all pins NC and test if NC is at all pins. If aren't there may be
error with IC Tester device itself, write error message and ask to continue.
- Set power up and check if power up is really working, if not tested IC
maybe in short circuit, write error and ask to abort testing.
- Test if there are on all inputs of tested IC +5V or NC, if not, IC is
probably damaged and in most cases you can't use that input.
- If there's more parts in tested IC like gates, set +5V to inputs of one
gate and check if there's respond from it.
Then check others inputs on others gates to see if there may be break from this
gate. Repeat this test for each gate.
- Now perform the same tests described in last entry, only this time set GND
to input pins of one gate. In this way you can cover all possibilities of
breaking from one gate to other.
- If you have IC with more gates, perform binary count on all inputs of each
gate to test if gate logic works.
- By this point all entries was standard testing, if there was error you can
safely ask to abort testing, because tested IC is probably damaged.
- Perform full test at all inputs with binary count to make sure that all
logic on tested IC working properly.
If you wrote test file and you want to share it, take a look in Feedback
section for more details.
Database files
From program version 0.0.6 there is available database which contains all data
as analyze data files, but in smaller format and more compact.
All test data what you write in analyze data file you can import to database
and export from it back to analyze data file of course.
Database file are in binary form and it's modified or generated by
ictdataedit program. It's graphical program and requires X-windows
environment and gtk+ graphic library.
Here I'll describe only construction of database, if someone want to make own
program for manipulating with database file. Note: you can download source code
of program and see how ictdataedit program work with database.
Legend:
Green color : Size of entry in database
Red color : Entry of variable size in database
Black color : Standard text for explanations or
naming some part Normal color : for additional information.
Here is structure from first byte to last:
[2 bytes database
identification (0xFF and 0x00)]
[1 byte version of current
database (from 0x00 to 0xFF)] Beginning of single test entry.
Next part is data part from single analyze test file and that structure can
repeating until reach end of file (Eq. if you have more analyze test files in
database).
[1 byte size of string
for link or test file name (7400), mixed with first bit
of this byte is type of data (link or data file): 1xxxxxxx - link,
0xxxxxxx - test file]
[string of test file name, max 128 chars]
If this is link entry then only in this case there will be this entry:
<1 byte size of string
for link location><string of link location, max 128 chars> otherwise
it will continue with:
[4 bytes size of the rest
test file entry]
[1 byte size of string
][string of true name (SN 7400), max 255 chars
]
[1 byte size of string
][description of IC test name (4xNAND), max 255
chars]
[2 bytes size of string
][ list of tested ICs, max 65025 chars]
[2 bytes size of string
][list of author names and/or e-mail, max 65025
chars] [20 bytes
for date - YYYY/MM/DD-HH:MM-ZONE]
[4 bytes
size of additional data]
In ictester program this 4 bytes is using as skip value. In that area is place
pictures for IC pinout, tables of truth, additional information, etc...
That part of database is using graphical test program xictester who will
be available for Linux and Windows when gtk+ library will be completely ported
on windows. When xictester program comes out then here will be described in
details this part of database.
From this point is data for testing IC to end of this test entry. It means that
you must from total size of entire test entry (you got this value at beginning)
subtract total size of all read entries so far and after that you know how
large is next test data part. O.k. here is what you can find in this:
[1 byte action:
0 - write data, 1 - read data, 2 - error report, 3
- ask report, 4 - pause]
After that action byte goes data in next forms:
[4 bytes for read
(R:) and write (W:) actions, where standard 16 characters data
are converted with next form: original entry - 1==10==1000==1=1; converted into
4 binary entries: 10010001(rw) 01100110(ign) 00000101(rw) 00011010(ign); and
finally converted from binary to decimal or hexadecimal: 145 102 5 26]
[1 byte size of string
for error (E:) and ask (?:) actions]
[ask or error string report]
[1 byte size of string
for pause][max 10
characters for string of long number]
With this ends test data entry block, if there is more imported analyze test
files it will be wrote continuously after, in exact form as described entry in
database.
You can also see currently supported ICs for full testing in supported file.
 
(C) Copyright Silvio Klaic, you can write to me at
sklaic@student.math.hr
|