search

DavidGriffith / minipro-import-test

An open source program for controlling the MiniPRO TL866xx series of chip programmers
GNU General Public License v3.0
3 stars 0 forks source link

Testing TTL chips #77

Open DavidGriffith opened 7 years ago

DavidGriffith commented 7 years ago

Created by: slseed1969

The TL866 is capable of testing IC chips with the Windows app. Is it possible to use the minipro command to test TTL's such as the 74HC86? I see that the chip is listed in the supported output, but how do I verify that it is working? Is it just a matter or reading it and comparing the hex output to a known good chip?

DavidGriffith commented 6 years ago

Created by: elosha

Currently, there is no dedicated testing procedure for logic ICs implemented.

I just tried what you suggested with two CD4051 multiplexers:

$ minipro -p 4051 -r cd4051-1.bin
Found Minipro TL866A v03.2.80
Reading Code... OK
Reading Data... OK
$ minipro -p 4051 -r cd4051-2.bin
Found Minipro TL866A v03.2.80
Reading Code... OK
Reading Data... OK
$ diff cd4051-1.bin cd4051-2.bin 
[no difference]

Contents of both identical files (hex):

36 30 31 31 34 39 33 32 43 30

But it also read the data area (which?) and dumped each a 41KB eeprom.bin:

36 30 31 31 34 39 33 32 43 30 44 35 38 31 35 41
30 46 43 30 33 46 45 32 38 44 44 34 46 46 35 38
75 3A 03 A0 21 D6 4F 5C 0D B2 DB 58 39 CE A7 94
A5 2A B3 10 51 C6 FF CC 3D A2 8B C8 69 BE 57 04
D5 1A 63 80 81 B6 AF 3C 6D 92 3B 38 99 AE FF 0B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[recurring]

Like a full lenght version of the above. It doesn't work very elegantly, but in this case it does the job and maybe it's a starting point.

If it happens that this method functions reliably accross manufacturer and technology variations, we could think about supplying a checksums for logic ICs in the device DB.

DavidGriffith commented 5 years ago

marked #119 as a duplicate of this issue

DavidGriffith commented 5 years ago

Also looking to implement testing of CMOS chips.

DavidGriffith commented 5 years ago

In GitLab by @radiomanV on May 31, 2019, 14:19

The minipro software logic IC testing is using only the pin manipulation primitives.
These are simple to understand ( https://gist.github.com/radiomanV/69ef14c704325bfa58339f2ae73a900f ) but unfortunately each chip have the testing algorithm hardcoded in the minipro.exe. There's no config file/table or anything to extract. Just pure x86 asm.

It should be an easy task for combinational (gates) logic chips to make some config/table structure and a universal algorithm to scan and compare results. For sequential chips (counters, flip-flops, shift registers and so on) this should be more elaborated and complex.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jun 27, 2020, 09:31

I started an implementation to check programmed ATFs. It uses test vectors like the ones defined by CUPL, e.g. something like this for a NAND:

VECTORS:
01H
10H
11L

This way you can define any logic and for PAL/GAL/ATF you typically already have created existing test vectors and I just want to reuse those files.

I haven't understood all the USB commands I need, maybe you can help me out:

Here an example of a test run without a chip, just reading back the set voltages:

$ minipro -p "ATF22V10C" -T test.si
Found TL866II+ 04.2.114 (0x272)
Vector:ZZZZZZZZZZZ0ZZZZZZZZZZZ1 H:111111111110111111111111 L:000000000000000000000001 M:ZZZZZZZZZZZ0ZZZZZZZZZZZ1
Vector:010110101011111111101011 H:010110101010111111101011 L:010110101010111111101011 M:010110101010111111101011
Vector:000********0111*******11 H:000111111110111111111111 L:000000000000111000000011 M:000ZZZZZZZZ0111ZZZZZZZ11

"H:" are the readings with pullup enable, "L:" with pulldowns enabled and "M:" the merged intermediate result.

This can be used with any logic chip, when you have the respective test vectors. There is a hardware limitation for chips with more than 32 pins, that not all pins can be tested. Timing can not really be tested, because the USB commands need milliseconds and the normal timing is in nanoseconds.

First check-in can be found here: https://gitlab.com/michael.dreher42/minipro/-/tree/logic_test

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jun 28, 2020, 09:42

Interesting approach.

TL866IIPLUS_SET_VCC_VOLTAGE: how can I set any other voltage than 4.5V?

There's a strange sequence of setting the VCC or VPP voltage. Let's try to make some light here. Here is the schematic diagram:https://github.com/radiomanV/TL866/blob/master/docs/TL866II.pdf
As we can see both VPP and VCC voltages are 4 bit resolution controlled, so we have 16 voltage levels.
We have the following VPP voltages:

1=9.0
2=9.5
3=10.0
4=11.0
5=11.5
0=12.0
6=12.5
7=13.0
8=13.5
9=14.0
10=14.5
11=15.5
12=16.0
13=16.5
14=17.0
15=18.0

And the following VCC voltages:

0=1.9
1=2.7
2=3.0
3=3.3
4=3.6
5=3.9
6=4.1
7=4.5
8=4.8
9=5.0
10=5.3
11=5.5
12=6.0
13=6.3
14=6.5
15=7.0

These values are measured at the ZIF pins (pin 1 for VCC/VPP and pin 20 for the GND) and may differ from programmer to programmer.

If you want to set the VPP voltage use this sequence:

int set_vpp_voltage(uint8_t voltage) { //VPP voltage = 0-15 see the table above
  uint8_t msg[48];
  memset(&msg[8], 0, 40);
  uint8_t b[] = {0,8,1,9,2,10,3,4,11,12,5,13,6,14,7,15};//Internal VPP table firmware map
  msg[0] = TL866IIPLUS_SET_VPP_VOLTAGE;
  msg[8] = (b[voltage] & 0x01);
  msg[9] = ((b[voltage] >> 1) & 0x01);
  msg[10] = (b[voltage] >> 2)& 0x01;
  msg[11] = (b[voltage] << 4) & 0x80;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }
   return EXIT_SUCCESS;
}

The VCC voltage can be set in the same manner:

int set_vcc_voltage(uint8_t voltage) { //VCC voltage = 0-15 see the table above
  uint8_t msg[48];
  memset(&msg[8], 0, 40);
  uint8_t b[] = {0,1,2,4,3,5,6,8,7,9,10,12,11,13,14,15};//Internal VCC table firmware map
  msg[0] = TL866IIPLUS_SET_VCC_VOLTAGE;
  msg[8] = (b[voltage] & 0x01);
  msg[9] = ((b[voltage] >> 1) & 0x01);
  msg[10] = (b[voltage] >> 2)& 0x01;
  msg[11] = (b[voltage] << 4) & 0x80;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }
   return EXIT_SUCCESS;
}

Note the different internal voltage maps.

Is it ok to use TL866IIPLUS_SET_GND_PIN / TL866IIPLUS_SET_VCC_PIN for the power pins of the chip or do I have to use TL866IIPLUS_SET_VPP_PIN when it supports the needed voltage?

Use TL866IIPLUS_SET_GND_PIN for the GND pin rail and the TL866IIPLUS_SET_VCC_PIN for the power pin rail. If you need a voltage over 7V to power a chip use TL866IIPLUS_SET_VPP_PIN but you'll need to pay attention to the pin map.

TL866IIPLUS_SET_OUT: is it possible to set GND and VCC with just this command instead of using TL866IIPLUS_SET_GND_PIN / TL866IIPLUS_SET_VCC_PIN? If yes, how are the pin mappings?

No you can't because these are controller I/O lines (resistor limited, see schematic diagram) so you don't have enough juice to power a chip in a such manner.

Pin mapping for all three pin drivers (VCC, VPP and GND) are declared in tl866iiplus.c as arrays (vcc_pins[], vpp_pins[], gnd_pins[]) and enums (VCC_PINS, VPP_PINS, GND_PINS).
Setting a pin driver is something like this (we set the zif pin 1 in this example): 

//Set a VPP pin driver
uint8_t msg[48];
 memset(&msg[8], 0, 40);
  msg[0] = TL866IIPLUS_SET_VPP_PIN;
  msg[vpp_pins[VPP1].byte] = vpp_pins[VPP1].mask;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }

//Set a VCC pin driver
 memset(&msg[8], 0, 40);
  msg[0] = TL866IIPLUS_SET_VCC_PIN;
  msg[vcc_pins[VCC1].byte] = vcc_pins[VCC1].mask;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }

//Set a GND pin driver
 memset(&msg[8], 0, 40);
  msg[0] = TL866IIPLUS_SET_GND_PIN;
  msg[gnd_pins[GND1].byte] = gnd_pins[GND1].mask;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }

// Don't forget to reset all pin drivers at the end
  // Reset pin drivers state
  msg[0] = TL866IIPLUS_RESET_PIN_DRIVERS;
  if (msg_send(handle->usb_handle, msg, 8)) {
    return EXIT_FAILURE;
  }

TL866IIPLUS_READ_PINS: after reading the response, I check response[1] != 0 for overcurrent protection and it is always set, but I did not even insert a chip. Is this the right way of checking overcurrent?

Yes, this is the right way. Make sure that you don't set the same pin to vcc/vpp and gnd or clear the read buffer with memset before the TL866IIPLUS_READ_PINS command

This is for TL866II+. For the old TL866A/CS we have some similar primitives, for ex. https://gitlab.com/DavidGriffith/minipro/-/blob/master/tl866a.c#L662 but there's no primitives to set the VCC/VPP voltage (or i don't know how).

The minipro/xgpro software uses a big switch case for every logic chip tested. In begin transaction command you pass the logic protocol, the chip variant and the firmware will set the power pins for you (for ex. pin 7=gnd, pin 14=vcc for a 74LS00 chip), then in that big switch case you set which pins are inputs and which are outputs. The test procedure is a big switch case also, according to a truth table every input pin is toggled high/low and the output pins are read to construct a test sequence.
I don't like this approach. I would make a file where each chip is described somewhat (pin count, which pins are inputs and which are outputs, the related firmware protocol to power the chip properly and the test sequence.)
Then we can implement some low level test routines for both TL866A/CS and the TL866II+.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jun 28, 2020, 15:17

@DavidGriffith: Thanks for the information, I will look at the details next week.

It looks like pin 12 is always GND and pin 40 always +5V and that's probably the reason for overcurrent error. That might come from the device selection of ATF22V10B.

The Wellon VP-598 programmer is an example with user defined test vectors, in chapter "11.3.1 Edit Pattern" of it's documentation you can find their definition of the test vectors. Hopefully there are already open source test vector databases for logic chips.

I will start to use the test vector definition of CUPL (.si and .sim file), because that's what the people already have when they use CUPL. CUPL is missing a way to tell the GND+power pins and the voltage, so this either comes from a device database or an extra user provided file.

CUPL's device database does at least contain the information about the GND+power pins:

Mnemonic:  g22v10
Pin Count:  24
Special Options:  None
Alternate Part Numbers:  ATF22V10B, ATF22V10BQ, ATF22V10BQL
Related Mnemonics:  p22v10

**************************************************
Pin#     Function
     1     CLK/IN
     2     IN
     3     IN
     4     IN
     5     IN
     6     IN
     7     IN
     8     IN
     9     IN
    10     IN
    11     IN
    12     GND
    13     IN
    14     IO
    15     IO
    16     IO
    17     IO
    18     IO
    19     IO
    20     IO
    21     IO
    22     IO
    23     IO
    24     VCC
DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 2, 2020, 22:53

Setting the voltage works now. The order between the calls matters. I figured out that you have to call set_vcc_voltage() after setting TL866IIPLUS_SET_VCC_PIN, because TL866IIPLUS_SET_VCC_PIN sets the Voltage always around 4.3V. I also tried to set the bytes 1 to 7 of the TL866IIPLUS_SET_VCC_PIN telegram to different values in the hope to set the pins and voltage in a single command, but there was no difference.

Now I understand, that I don't need to set the voltage, because minipro_begin_transaction() already does this. Trying to figure out the meaning of the lower 16 bits of handle->device->opts5 I found out the following: The bits 4 to 15 have no direct influence on the voltage, at least when TL866IIPLUS_SET_VCC_PIN is not used.

The lower 4 bits of handle->device->opts5 have the following meaning for the ATF22V10C(UES) Vcc voltage (measured voltage):

It needs to be verified how the real waveform looks using an scope because I fear there may be some glitches when switching from one vector to the next one. For pure stateless logic ICs this doesn't matter, but when using latches or flip-flops and clocks this would be a problem.

minipro_begin_transaction() defines some fixed values. That means I'm bound to the buitin device database which defines those pins or I have to change the implementation of minipro_begin_transaction() to make it more flexible, but then I need more knowledge about the fields of device_t.

My current implementation state is, that setting the inputs and reading the output seems to work pretty well. There is only one problem left: ZIF Pin 29 (device pin 13) is read as '1' when it is set to '0'. ZIF Pins 1 to 12 and 30 to 40 work for '0', '1' and 'Z' (ZIF pins 13 to 28 have not been tested, yet):

v_in: 000000000000000000000001
v_out:000000000000100000000001
v_err:            1

A test with another TL866IIpro has show the same problem, but that one has an additional problem: ZIF pin 30 is read as '1' when ZIF pin 29 is set to '1' and vice versa. When one of those pins is '0' it gets even more strange.

@DavidGriffith :

Unfortunately I cannot debug minipro on my Mac, starting it just shows the following lines and hangs (although I went through the painful process of codesigning ggdb):

(gdb) r
Starting program: /Users/michael/Downloads/minipro_logic_test/minipro -p ATF22V10B -T A1000K11.si
[New Thread 0x2703 of process 47904]

It can only be stopped with kill -9.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 3, 2020, 08:27

@michael.dreher42 please pay attention to who actually responded to you.

also tried to set the bytes 1 to 7 of the TL866IIPLUS_SET_VCC_PIN telegram to different values in the hope to set the pins and voltage in a single command, but there was no difference.

The first 8 bytes are part of the message header and are used only on some commands like TL866IIPLUS_BEGIN_TRANS and others to set the protocol, device variant and so on.

Using the begin_transaction()/end_transaction() functions in this case is plain wrong. Let me explain.
When you issue a begin_transaction() command then the firmware will internally switch to an existing protocol.
The device->protocol_id, variant and the other init members are used to initialize the pin drivers, chip voltage, programming voltage, buffer size, timing and other various parameters according to an existing protocol (for ex. i2c, spi, parallel eproms or various controllers). The end_transaction() will reset all pin drivers, flush any used buffers and reset the internal state of the programmer.

Logic chip test doesn't have a specific protocol. You can manipulate/check any pin you want without any restriction. Once you switched to any existing protocol with begin_transaction() you are locked.
Also the logic test protocol implemented in the firmware is only for setting the VCC/GND pins and VCC voltage but once you issue a begin_transaction() with protocol_id = 0 then you are restricted to 28 or 24 pin devices if i remember correctly (same as the TL866A/CS).

So it is way better to bypass any firmware protocol and manually set the GND/VCC pins and after that set the VCC voltage (yeah, in this order) then you really need to check the ovc to see if something is wrong with the chip (otherwise when an over current condition is triggered the firmware will reset all pin drivers and you are testing nothing).

Something like that:

// you can pass some handle or a table index for example
int logic_test_init(minipro_handle_t *handle){
  // Set VCC on pin 40 
  memset(&msg[8], 0, 40);
  msg[0] = TL866IIPLUS_SET_VCC_PIN;
  msg[vcc_pins[VCC40].byte] = vcc_pins[VCC40].mask;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }

  // Set GND on pin 12
  memset(&msg[8], 0, 40);
  msg[0] = TL866IIPLUS_SET_GND_PIN;
  msg[gnd_pins[GND12].byte] = gnd_pins[GND12].mask;
  if (msg_send(handle->usb_handle, msg, sizeof(msg))) {
    return EXIT_FAILURE;
  }

tl866iiplus_set_vcc_voltage(handle, 9);//set the VCC to 5V

//Check for over current condition
 uint8_t ovc;
if (tl866iiplus_get_ovc_status(handle, NULL, &ovc)) return EXIT_FAILURE;
   if (ovc) {
     fprintf(stderr, "Overcurrent protection!\007\n");
     return EXIT_FAILURE;
   }

return EXIT_SUCCESS;
}

Then you can play with bit banging primitives.

minipro_begin_transaction() defines some fixed values. That means I'm bound to the buitin device database which defines those pins or I have to change the implementation of minipro_begin_transaction() to make it more flexible, but then I need more knowledge about the fields of device_t.

Where in device_t can I find the pin numbers of the Vcc and GND pins of the device so I can exclude them from the test patterns?

The device_t doesn't define any gnd or vcc pins. That's why you use begin_transaction(), the firmware will handle this for you (but then you are locked to a protocol).

A test with another TL866IIpro has show the same problem, but that one has an additional problem: ZIF pin 30 is read as '1' when ZIF pin 29 is set to '1' and vice versa. When one of those pins is '0' it gets even more strange.

do you have and idea what could be the cause of the problem with ZIF pins 29 and 30?

Please issue a hardware test (minipro -t) first to check all VCC/VPP/GND pin drivers.

Most likely you read some floating state input and you have some interferences or crosstalk between the pcb traces.

You can make a test sequence to test the I/O lines. Something like this:

As a suggestion you can move the logic test code from main.c to a new file say logic.c/logic.h and keep the low level functions implemented in tl866iiplus.c as they are.
This way we can define a database for every supported logic chip. You can peek at the pin_map.h to get an idea. Something like this:

typedef struct logic_chip {
    uint8_t pin_count;
    uint8_t gnd_pins [4];
    uint8_t vcc_pins [4];
        uint8_t vcc_voltage;
} logic_chip_t;
This way we can define four vcc pins and four gnd pins.

Then we can define a logic chip entry like this:

logic_chip_t logic_chip_table[] = {
{    // 0x00
    .pin_count = 14,
    .gnd_pins = {7, 0, 0, 0},
    .vcc_pins = {14, 0, 0, 0},
    .vcc_voltage = 9;
},
//......................................

Then we can use the protocol_id and variant from the device_t structure to map the device to this table. For the Logic devices (protocol 0x00) should be only three entries in this table (variant 0x07, 0x08, 0x0a). For testing PLD devices also max. four entries to define all supported chips.
This way we can extend the device_t structure for logic test with some low level definitions.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 3, 2020, 13:03

good ideas, I have implemented it that way, see https://gitlab.com/michael.dreher42/minipro/-/blob/logic_test/logic.c#L453

Please issue a hardware test (minipro -t) first to check all VCC/VPP/GND pin drivers.

There is no error with the normal -t test.

You can make a test sequence to test the I/O lines.

The test vectors almost do it that way, but they read with either pull-up or pull-down enabled because this is the only way to tell if an output is in 'Z' state. Maybe this pull-up is too small or the driver is too weak.

If you want to give the code a try, you just call it like this:

iMac:minipro_logic_test michael$ ./minipro -T 'device_tests/ATF22V10C(UES)/A1000K11/A1000K11.si'
Found TL866II+ 04.2.115 (0x273)
Warning: Firmware is newer than expected.
  Expected  04.2.111 (0x26f)
  Found     04.2.115 (0x273)
v_in: ZZZZZZZZZZZZZZZZZZZZZZZZ
v_out:ZZZZZZZZZZZGZZZZZZZZZZZV
v_err:                        

v_in: 000000000000000000000000
v_out:00000000000G10000000000V
v_err:            1           

v_in: 111111111111111111111111
v_out:11111111111G11111111111V
v_err:                        
...

Currently you need to hit enter after every test vector because some times I want to measure the voltage. The stop point is always in the state when the pull-downs are active.

You might also have a look where I set the outputs: https://gitlab.com/michael.dreher42/minipro/-/blob/logic_test/tl866iiplus.c#L1121

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 4, 2020, 06:10

reading the test data from files is now finished, only the device data is still hardcoded. This is the only implementation step missing. Maybe another output format which can be shown in WinCUPL.

I was able to test my ATF22V10C(UES) using the unmodified test vectors from WinCUPL and the dry-test no_real_device.si also works without problems now.

The overcurrent problem was caused by applying vector[n+1] while the vector[n] was still enabled. When a pin is switched from 1 to 0, both the Vpp and the GND driver were active because of the order I switch the pins. I now introduced an intermediate step: when switching a pin from 0 to 1 or 1 to 0, the pull-down is used as intermediate step. This should avoid glitches which would cause problem with clock lines and latches.

Please have a look at the test vector files in https://gitlab.com/michael.dreher42/minipro/-/tree/logic_test/device_tests/ATF22V10C(UES).

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 5, 2020, 24:53

I was looking for test vector files. Googling for test vector "C11XVXXLLGLLXC" revealed a file called "Test.lib" from Wellon which looks good. The whole Wellon software can be downloaded from here. It includes 2 test vector database files:

"Max Loader" from EETools can be downloaded from here. It uses this test vector database file:

Searching for other vectors like "00H00HGH00H00V" and "10H10HGH10H10V" found some more hits like this and that site.

(Win)CUPL test vectors work with logical pins, that means the test vectors are based on the order of the symbols in the "ORDER:" statement and doesn't include the power pins, the mapping of the pins to the symbols comes from the file ".sim" file.

For PAL/GAL/ATF that makes sense, because you don't want to adapt your test vectors just because you choose to change the pin assignment of your signals and you also don't care to define the power pins for every line of your test vector. For mask defined chips that logical to physical mapping is not really necessary.

Wellon work with physical pin numbers and include also the power pins in their vector. Here any example from their test vectors:

7400 05 14
00H00HGH00H00V
10H10HGH10H10V
01H01HGH01H01V
11L11LGL11L11V

The meaning of the two numbers after the "7400" is the following:

I now implemented it the following way: When the file extension is ".si" the PAL/GAL/ATF logical pin mode is assumed. In that case the second file with ".sim" extension is loaded for the logical to physical pin mapping. The power pins and the number of pins is needed here as additional information.

Any other file extension is taken as physical (raw) test vectors without any header. Power pins and number of pins is contained implicitly in the test vectors.

Both cases miss the Vcc voltage.

A third mode is needed to load a library file and pass a model number as additional parameter to select a device from that library. Typically a standard library would be delivered together with minipro and user libraries could be loaded on request.

Please see the examples of the 74xx device files 7400.si and 7400.raw in the device_tests/74xx.

You can now run ./minipro -T device_tests/74xx/7400_simplistic/7400.raw. Unfortunately I don't have a real one but I emulated one using and ATF22V10C (had to move 1Y and 2Y pins)

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 5, 2020, 09:54

New milestone reached: I can now use the device database from EETools, this command looks up the database and uses its vectors:

./minipro -p "7400" -T device_tests/libs/lg.dat
Found TL866II+ 04.2.115 (0x273)
Warning: Firmware is newer than expected.
  Expected  04.2.111 (0x26f)
  Found     04.2.115 (0x273)
v_in [  1]:11L00HGH00H00V
v_out[  1]:11Z00ZGH00H00V
v_err[  1]:  Z  Z        

v_in [  2]:00H00HGH00H00V
v_out[  2]:00Z00ZGH00H00V
v_err[  2]:  Z  Z        

v_in [  3]:01H00HGH00H00V
v_out[  3]:01Z00ZGH00H00V
v_err[  3]:  Z  Z        
...

PS: the errors for pins 3 and 6 are expected because my ATF22V10C has only output pins from 14 to 23.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 6, 2020, 11:46

Unfortunately i had no time in this weekend to play, but now i opened my old box full of logic chips (over 2000 i think) and give it a go.
Tested couple of 7400 series chips: 7400, 7403, 7404, 7493, 7430, 7495, 7473, 7474, 74153, 7492, 7410, 7442, 74193, 7486.
All tests went ok except for the 7495 and 74193.

7495:

./minipro -p "7495" -T device_tests/libs/testvectors_merged.dat 
Found TL866II+ 04.2.115 (0x273)
v_in [  1]:X00001GCC0000V
v_out[  1]:Z00001G000000V
v_err[  1]:              

Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
v_in [  2]:X11111GCC1111V
v_out[  2]:Z11111G001111V
v_err[  2]:              

Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
v_in [  3]:XXXX01GCC0XXXV
v_out[  3]:Z11101G000111V
v_err[  3]:              

Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
v_in [  4]:XXXX11GCC1XXXV
v_out[  4]:Z11111G001111V
v_err[  4]:              

Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
v_in [  5]:1XXXX0GCCXXXHV
v_out[  5]:1ZZZZ0G00111HV
v_err[  5]:              

Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
Error: Overcurrent protection detected while reading pin state
v_in [  6]:0XXXX0GCCXXXLV
v_out[  6]:0ZZZZ0G00111LV
v_err[  6]:

I think that we should abort the test after the first overcurrent protection.

74193:

./minipro -p "74193" -T device_tests/libs/testvectors_merged.dat 
Found TL866II+ 04.2.115 (0x273)
v_in [  1]:1HH01HHG110XX01V
v_out[  1]:1HH01HHG1101101V
v_err[  1]:                

v_in [  2]:1HLC1HHG111XX01V
v_out[  2]:1HL01HHG1111101V
v_err[  2]:                

v_in [  3]:1LHC1HHG111XX01V
v_out[  3]:1LH01HHG1111101V
v_err[  3]:                

v_in [  4]:1LLC1HHG111XX01V
v_out[  4]:1LL01HHG1111101V
v_err[  4]:                

v_in [  5]:1HH1CLHG111XX01V
v_out[  5]:100101HG1111101V
v_err[  5]: 00  1          

v_in [  6]:1LL1CHHG111XX01V
v_out[  6]:1L110HHG1111101V
v_err[  6]:  1             

v_in [  7]:1LH1CHHG111XX01V
v_out[  7]:11010HHG1111101V
v_err[  7]: 10             

v_in [  8]:1LLC1LLG111XX11V
v_out[  8]:1LL01LLG1111011V
v_err[  8]:

I think that we have some glitches here or else...

Also tested some CMOS 4000 series: 4001, 4002, 4053, 4066, 4518, 4093, 4024, 4028, 4520, 4511
All ok except for the 4511:

./minipro -p "4511"  -T device_tests/libs/testvectors_merged.dat 
Found TL866II+ 04.2.115 (0x273)
v_in [  1]:0001000GHHHHHHHV
v_out[  1]:11111111HHHHHHHV
v_err[  1]:111 1111        

v_in [  2]:0011001GLLHHLLLV
v_out[  2]:11111111LLHHLLLV
v_err[  2]:11  11 1        

v_in [  3]:0111001GLHHLHHHV
v_out[  3]:11111111LHHLHHHV
v_err[  3]:1   11 1        

v_in [  4]:0011000GHHHHHLHV
v_out[  4]:11111111HHHHHLHV
v_err[  4]:11  1111        

v_in [  5]:0010000GLLLLLLLV
v_out[  5]:11111111LLLLLLLV
v_err[  5]:11 11111

Also i tested two old MCS80 chips alreday in the database (8255 and 8259). . For the 8259 i got an overcurrent protection and for 8255 PPI this:

./minipro -p "8255"  -T device_tests/libs/testvectors_merged.dat 
Found TL866II+ 04.2.115 (0x273)
v_in [  1]:XXXX11GXXXXXXXXXXXXXXXXXXVXXXXXXXX11XXXX
v_out[  1]:ZZZZ111ZZZZZZZZZZZZZZZZZZVZZZZZZZZ11ZZZZ
v_err[  1]:      1                                 

v_in [  2]:010100G00XXXXXXXXXXXXXXXXVLHLHLHLH010101
v_out[  2]:111111111ZZZZZZZZZZZZZZZZVZZZZZZZZ111111
v_err[  2]:1 1 11111                 ZZZZZZZZ1 1 1 

v_in [  3]:101000G00XXXXXXXXXXXXXXXXVHLHLHLHL011010
v_out[  3]:111111111ZZZZZZZZZZZZZZZZVZZZZZZZZ111111
v_err[  3]: 1 111111                 ZZZZZZZZ1  1 1

Error: Device pin 17 (zif pin 17) cannot be set to '0'
Error: Device pin 18 (zif pin 18) cannot be set to '1'
Error: Device pin 19 (zif pin 19) cannot be set to '0'
Error: Device pin 20 (zif pin 20) cannot be set to '1'
Error: Device pin 22 (zif pin 22) cannot be set to '1'
Error: Device pin 23 (zif pin 23) cannot be set to '0'
Error: Device pin 24 (zif pin 24) cannot be set to '1'
Error: Test vector with pull-ups failed

Is this ok?

    if(state[i] == '1' || state[i] == 'V') {
      if(tl866iiplus_pin_set_bit(vcc_pins, sizeof(vcc_pins)/sizeof(vcc_pins[0]), msg_vcc, zif_pin)) {
        ret = EXIT_FAILURE;
        fprintf(stderr, "Error: Device pin %d (zif pin %d) cannot be set to '1'\n", dut_pin, zif_pin);
      }
    }
    else if(state[i] == '0' || state[i] == 'G') {
      msg_dir[USB_MSG_HEADERLEN + zif_pin - 1] = 0;
      if(tl866iiplus_pin_set_bit(gnd_pins, sizeof(gnd_pins)/sizeof(gnd_pins[0]), msg_gnd, zif_pin)) {
        ret = EXIT_FAILURE;
        fprintf(stderr, "Error: Device pin %d (zif pin %d) cannot be set to '0'\n", dut_pin, zif_pin);
      }
    }

Because we can set any pin to logic '0' or '1' but we cannot set every pin to VCC or GND.

The v_in, v_out and v_err messages are ok for the debug purposes but i think we should print more human friendly messages like Chip test passed and Chip test failed. This way we can test large amount of chips very fast. Perhaps we should print v_in, v_out and v_err messages only when a chip test fails.

Now about the database. Where should be located? something like /usr/share/minipro? Because we have the issue #178. Also, this project can be compiled under Windows and that path doesn't exist. Should we define this database as a big string perhaps? specifying the path to the database every time when we test a logic chip is not so elegant. Also what should we do with the logic chips already defined in infoic_devices.h/infoiciiplus_devices.h?

For example this is how the 7400 is defined in the current database:

{
    .name = "74HC(LS)00",
    .protocol_id = 0x00,
    .variant = 0x07,
    .read_buffer_size =  0x80,
    .write_buffer_size = 0x20,
    .code_memory_size = 0x0a,
    .data_memory_size = 0x00,
    .data_memory2_size = 0x00,
    .chip_id = 0x0000,
    .chip_id_bytes_count = 0x00,
    .opts1 = 0x00,
    .opts2 = 0x0000,
    .opts3 = 0x0000,
    .opts4 = 0x0080,
    .opts5 = 0x0000,
    .opts6 = 0x0000,
    .opts7 = 0x0000,
    .opts8 = 0x0000,
    .package_details = 0x0e000000,
    .config = NULL
},

Only protocol_id = 0x00 and variant = 0x07 are used by the original windows software to inform the firmware to set the VCC to 5V and to what pins (variant member) to apply this voltage. But we don't need those parameters. Maybe only the package_details it is somewhat helpful indicating the pin count but this can be deduced from the test vector itself.
Then we should delete all those definitions from the infoic_devices.h/infoiciiplus_devices.h and extend the -l and -L to search in the .dat database.

Also many users still use the old TL866A/CS. Low level functions implemented in tl866iiplus.c should be implemented in tl866a.c. The big problem is with pull-up/pull-down resistors. We have no pull-down resistors in TL866A/CS. Also pull-up resistors can be enabled/disabled only at once for all pins.

For the VCC voltage should we set it to 5V for all tested chips?

I will import your branch into Eclipse CDT (i really like the eclipse gdb debugger implementation) to debug some of the unsupported chips like 7495 and 74193.

I really like how the logic test is implemented because we can easily define our own test vectors.

devname_len--; // TODO: what is the meaning of the '*' at the end of the device name?

I think these devices are open-collector/open-drain outputs compared to normal devices with totem-pole/push-pull outputs ;)

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 6, 2020, 12:48

only a short answer for today, longer one will follow later.

7495: that one uses 'C'. I never could test 'C' and 'K' until now, that's probably the problem.

74193I think that we have some glitches here

That might have the same problem with the 'C'.

4511

That is strange. The read back inputs don't match. Even the GND pin is read as '1'. The outputs are ok.

abort the test after the first overcurrent protection.

Sure, I activated that again.

'8255' Device pin 17 (zif pin 17) cannot be set to '0'. Is this ok? We can set any pin to logic '0' or '1'

Which commands do you mean?

Currently I use those commands:

I think I have still not understood the right combinations to use and also not the mapping to the hardware.

but we cannot set every pin to VCC or GND.

I use the VCC_PIN and GND_PIN command to set the logic voltage, that may be the problem.

Now about the database. Where should be located? something like /usr/share/minipro

Yes and %PROGRAMDATA%\minipro under Windows.

TL866A/CS.Also pull-up resistors can be enabled/disabled only at once for all pins.

That's no problem.

We have no pull-down resistors in TL866A/CS

This is a problem.

specifying the path to the database every time when we test a logic chip is not so elegant

At the moment there are 3 different modes supported:

  1. PAL/GAL/ATF: needs .si and .sim file + GND/Vcc Pins
  2. Logic chips from .dat database: needs chip name and optionally a filename of another .dat file
  3. Raw vectors from file without header (no specific file extension): no additional information needed

Probably we should use different commands for them. The 3rd one is not really needed and could be removed when we have 2nd.

For the VCC voltage should we set it to 5V for all tested chips?

I think most chips are 5V, but for example the CD45HC4511 has a voltage range from 2V to 6V. The CD74HCT4511 is 5V. That's why we should not bind the test vector to a specific voltage. The voltage should be a commandline parameter. The test database should only contain the pin and logic definition, otherwise it would explode.

A Wikpedia page says: about the CMOS devices:

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 6, 2020, 15:00

7495 v_in [ 1]:X00001GCC0000V

The test vectors are wrong. The last 4 '0' are the outputs Q0 to Q3, the vector should not write to an output. Can you please try the test vector lib 'testvectors2.dat'?

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 6, 2020, 15:44

7495: that one uses 'C'. I never could test 'C' and 'K' until now, that's probably the problem.

74193I think that we have some glitches here

That might have the same problem with the 'C'.

Well, i successfully tested a 7474 dual flip-flop, 7493, and 7473, which all use the C clock test signal and all is ok. Also the CMOS 4518, 4520 are ok and those also use the C.

I think I have still not understood the right combinations to use and also not the mapping to the hardware.

This is a pin driver: pin

We have two PNP transistors for the VCC and VPP voltage and one NPN transistor for the GND driver.
The ZIF pin is connected to the micro via a 510 ohm resistor and one voltage limiter diode.
So we can manipulate each I/O line (40 in total), we can set its direction (in/out), set it (0/1) or read its logic value. Also due to the micro used we can put a pull-up or pull-down resistor to each line if needed.

As you saw, setting one of those 40 I/O line is easy! we have the following commands:

TL866IIPLUS_SET_PULLDOWNS //to set all 40 pins pull-downs
TL866IIPLUS_SET_PULLUPS   //to set all 40 pins pull-ups
TL866IIPLUS_SET_DIR      //to set all 40 pins direction (in/out)
TL866IIPLUS_READ_PINS    //to read all 40 pins logic state
TL866IIPLUS_SET_OUT     //to set all 40 pins logic state (0/1; the pin must be set as out)

The VCC/VPP/ and GND drivers are a separate thing. We don't have a VCC/VPP or GND driver for each pin.
So we have these commands to open a power rail driver:

TL866IIPLUS_SET_VCC_PIN 
TL866IIPLUS_SET_VPP_PIN 
TL866IIPLUS_SET_GND_PIN

Also i hooked the scope to the power lines (pin 7 and 14) and started a debug session. Well interesting things!
The first thing is the voltage value: 5V with no chip inserted and aprox. 4.6 with a chip inserted. That's not so great. The power consuption of a 7400 logic chips should be max 20ma.
Another thing is that in the tl866iiplus_chiptest_setoutputs for loop (line 1091) you set the V and G for every vector. The voltage will flicker from 3.8v to 4.6v after every tested vector.
There should be a separate function called only once at the beginning of the test which will set the V and G pins and also the VCC voltage.

Then when the chip testing starts the V and G pins should be ignored.
So for the V we should use only TL866IIPLUS_SET_VCC_PIN and for the G only the TL866IIPLUS_SET_GND_PIN. The TL866IIPLUS_SET_VPP_PIN should not be used for logic test. We should use only the TL866IIPLUS_SET_VCC_VOLTAGE because we have a wide range of voltage values (1.8-7V). So no if(state[i] == '1' || state[i] == 'V') in that loop.
In the initial setup when a V or a G pin is encountered then we should set the corresponding I/O line as input with no pull-up or pull-down activated (HI-Z state).

Also the 1, 0, C and K symbols should use only TL866IIPLUS_SET_OUT because these pins are I/O lines not power rail pins. For example for the 7495 shift register pin 6 is wrongly set as VCC pin not as I/O output pin.

The test vectors are wrong. The last 4 '0' are the outputs Q0 to Q3, the vector should not write to an output. Can you please try the test vector lib 'testvectors2.dat'?

Tested. This time no overcurrent messages but still not good:

./minipro -p "7495" -T device_tests/libs/testvectors2.dat 
Found TL866II+ 04.2.115 (0x273)
v_in [  1]:XXXXX1G1XHHHHV
v_out[  1]:ZZZZ11G1Z0000V
v_err[  1]:         0000 

v_in [  2]:X01011GCXHLHLV
v_out[  2]:Z01011G0ZHLHLV
v_err[  2]:              

v_in [  3]:X10101GCXLHLHV
v_out[  3]:Z10101G0ZLHLHV
v_err[  3]:              

v_in [  4]:XXXXX0G01HHHHV
v_out[  4]:ZZZZZ0G010H0HV
v_err[  4]:         0 0  

v_in [  5]:0XXXX0GXCHHHLV
v_out[  5]:0ZZZZ0GZ00H0LV
v_err[  5]:         0 0  

v_in [  6]:1XXXX0G00HHLHV
v_out[  6]:1ZZZZ0G000HL0V
v_err[  6]:         0  0 

v_in [  7]:XXXXXCG00HHLHV
v_out[  7]:ZZZZZ0G000HL0V
v_err[  7]:         0  0 

v_in [  8]:XXXXXCG01HLHHV
v_out[  8]:ZZZZZ0G01HL0HV
v_err[  8]:           0  

v_in [  9]:XXXXXCG10HHHHV
v_out[  9]:ZZZZZ0G10HHHHV
v_err[  9]:              

v_in [ 10]:XXXXXCG11HHHHV
v_out[ 10]:ZZZZZ0G11HHHHV
v_err[ 10]:
DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 6, 2020, 23:44

This is a pin driver:

Thanks, that was the missing link!

The little schematic withing the "40x voltage limiter" is missing the labels and I had no clue to what it is connected. There should be labels P_n and ZIF_n at the left and right connectors and also a "20x" label above that little schematic.

Therefore it was not clear to me how the P_n is connected to ZIF_n. Now it is clear.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 6, 2020, 23:45

I have done some correction to the testing algorithm. You can check the result here: https://gitlab.com/radiomanV/minipro/-/tree/logic_test

The VCC(V), GND(G) and the VCC voltage pins are set at the beginning of the test. These pin assignment don't change for the entire test duration.
The 0 and 1 are implemented with TL866IIPLUS_SET_OUT. That intermediate step is eliminated (not needed anymore). Wast majority of the chips tested are ok, we still have some invalid vectors in the database ;)
The CMOS chip 4511 error is cured.

But we have a problem. The Z output detection for all open-collector/open-drain chips. For example the 7403 chip (Quad 2-Input NAND Gates with Open-Collector Outputs). According to the truth table we have:

00H
01H
10H
11L

The L state is detected ok but all H states are detected as floating Z in v_err which is not an error because this is how open-collector gates works. So we need to address this issue. I still need to test more sequential chips to see if we have some timing issues.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 6, 2020, 23:47

you can put a 'Z' state instead of 'H' in the test vector. Now I understand what that '*' at the end of the device name is good for, the 'H' in that device's test vector needs to be replaced by 'Z'.

I have done some correction to the testing algorithm. Y

me too :-)

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 6, 2020, 23:57

Yes, i used testvectors2.dat and there are no Z symbols. The testvectors_merged.dat is ok now. Thanks!

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 7, 2020, 22:42

I created a new test vector and tested that against my 7495 emulation with ATF22V10C, see 7495.dat. The original test vector was just wrong.

There are also lots of small fixes and I now use set_output.

Open collector devices with the '*' are also implemented, but not tested, yet.

@radiomanV : I sent you I private email to the yahoo address in your profile, did you get that? Otherwise please ping me at michael(o)5dot1.de.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 8, 2020, 03:01

I sent you I private email to the yahoo address in your profile, did you get that?

Yes, received and replied. Anyway i sent you a new repply from my personal e-mail address.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 10, 2020, 11:40

@radiomanV : now I cleanup up the code a bit

Open issues:

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 11, 2020, 13:03

@radiomanV : now I cleanup up the code a bit.

Tested hundreds of chips (TTL/CMOS) and we have a problem.
Tested something like 30-40 7493 and 7490 counters and first i thought that they are all burned. The official Xgpro software also shows them as defective units. But they are not.

For CMOS chips (4000 series / 74HC/HCT) we can reliably drive a logic gate with PIC I/O lines using TL866IIPLUS_SET_OUT but unfortunately we cannot drive some TTL chips. For the Logic '1' there's no problem but when we set a I/O line to logic '0' that line cannot sink enough current (for ex.the 7490 chip ClockB input requires approx 4.8 mA, for the logic '0', IiL parammeter) and obviously the TL866 will fail.

Look here (7490, ClockB input): cap2

As we can see the logic '0' voltage cannot go bellow 1.12V. So we have a big problem.
We must use a GND npn transistor driver to drive logic '0' lines together with the PIC I/O line.
Unfortunately the number of GND transistors is limited so we cannot use this trick for TTL chips with more than 32 pins. Fortunately, i don't know if something like this exists.
So in tl866iiplus_chiptest_setoutputs function we have to do this:

  else if(s == '0') {
      msg_dir[idx] = DIRECTION_OUTPUT;
      msg_out[idx] = 0;
      // Using a strong logic 0 driver 
      tl866iiplus_pin_set_bit(gnd_pins, sizeof(gnd_pins)/sizeof(gnd_pins[0]), msg_gnd, zif_pin);
    }

this code is not needed anymore

if((prev_state[zif_pin - 1] == 'G' && s != 'G')
        || (prev_state[zif_pin - 1] != 'G' && s == 'G')) {
      set_gnd = 1;
    }

and set the GND like this (set_gnd is not used anymore)

else if (msg_send(handle->usb_handle, msg_gnd, sizeof(msg_gnd))) {
    ret = EXIT_FAILURE;
    fprintf(stderr, "Error: SET_GND failed\n");
    goto cleanup;
  }

Fortunately, setting the GND pins with TL866IIPLUS_SET_GND_PIN doesn't alter the VCC voltage like the TL866IIPLUS_SET_VCC_PIN does. This way we have a stable VCC voltage.
The result is this: cap1
Pretty good! Also, i think we should print a warning message if the DUT is a TTL with more than 32 pins.

Test vectors database and Clock.
As i can see we have two symbols for clock generation. The 'C' for 0-1-0 transitions and 'K' for 1-0-1 transitions. The problem is that for ex the 'C' means two high to low transition for some chips. For example the 7495 shift register. So we must count this when create test vectors. Also, many test vectors are not reliable or pure wrong, so we should review every supported chip.
For example the above 7495. We should test its functionality and pin integrity with the smallest number of test vectors. Like this:

.7495 14
000001GC1LLLLV
011111GC1HHHHV
000000G1KHHHLV
000000G1KHHLLV
000000G1KHLLLV
000000G1KLLLLV

The first vector loads the shift register with 0000 and the second vector with 1111. This way we tested the parallel load function and P0-P3, D0-D3, S and /CP1 pins. Then we change the mode to serial and using the 'K' type clock we enter a logic '0' from the DS pin through all D0-D3 cells. This way we tested the serial shift function and the DS pin with a minimal number of test vectors.

Here are some vectors tested by me:

.7472 14
X0000HGL00011V
X1000LGH00010V
X1111HGL111C1V
.7490 14
100XV11LLGHHX1
111XV00LLGLLX1
100XV00LLGLHXK
100XV00LLGLLXK
K00XV00LHGLLX1
K00XV00HLGLLX1
K00XV00HHGLLX1
K00XV00LLGHLX1
.7493 14
111XVXXLLGLLX1
100XVXXLLGLHXK
100XVXXLLGLLXK
K00XVXXLHGLLX1
K00XVXXHLGLLX1
K00XVXXHHGLLX1
K00XVXXLLGHLX1
K00XVXXLHGHLX1
K00XVXXHLGHLX1
K00XVXXHHGHLX1
.74174 16
0L00L0LG1L0L00LV
1H11H1HGCH1H11HV
1L00L0LGCL0L00LV

The SN74174 test vector in the database is pure wrong.

As a suggestion the test failed/passed messages are ok but i think we should include a flag for verbosity if we want to see the entire output. At least for debugging purpose.

All chips i have tested (all kind of AND/NAND/OR/XNOR/XOR gates, flip-flops, shift registers, counters, multiplexers, decoders) TTL and CMOS technology were ok with the addition of the strong logic '0' above.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 11, 2020, 23:54

Thanks for doing all that tests!

As we can see the logic '0' voltage cannot go bellow 1.12V. So we have a big problem.

That problem is solvable, I checked in your change. Also changed for 'G' so 'G' and '0' now behave identical (only the warning/error message is different).

The discussion on this page tells that they discovered the same problem.

Also, i think we should print a warning message if the DUT is a TTL with more than 32 pins.

There is already an error message when you try to set a pin to an impossible value, that's why tl866iiplus_pin_set_bit has a returncode.

For '0' it is now only a warning: "Warning: Device pin %d (zif pin %d) cannot be set to strong '0', using weak '0'"

The 'C' for 0-1-0 transitions and 'K' for 1-0-1 transitions. The problem is that for ex the 'C' means two high to low transition for some chips. For example the 7495 shift register. So we must count this when create test vectors

Exactly that bite me when I created the 7495 test vector. The simple solution is:

The transition of clocks has to be done always using 'C' and 'K' because the other inputs are set first and after those are settled the 'C'/'K' are executed.

For the 7495 it is even more critical because the internal FlipFlop clock is created using a equation and input "S" switches between the two clocks. The datasheet says "For normal operation, S should only change states when both Clock inputs are LOW". Thats why I use 'C' and not 'K' in my latest test vectors, although the input clocks are inverted and the value is latched at the falling edge.

I would prefer -T without argument for the default database and -T path/to/mylib.dat for a custom dat file.

It could be done, but that's not the way normal CLI commands work. The reason is, that parsing would be ambiguous because "-p mylibfile.dat" and "-z" are valid filenames, so it is unclear what "-T -z" means.

An empty parameter or a special parameter "default" would be ok, but that is also unusual

Yes, I implemented now 6 levels using "-W -W -W -W -W -W", whereas 6x waits after applying each vector. Normal users would not use more than one or two "-W" and they don't have to think about a numeric parameter.

Level 5 looks like this:

L          010101L1LLLGLL00L00LLLLV
I          010101010000000010001001
L          110101L1LLLGLL00L10LLLLV
I          110101010000000001001011
L          010101L1LLLGLL00L00LLLLV
I          010101010000000010001011
H          010101H1HHHGHH00H00HHHHV
I          010101111110110010001011
v_inp [13]:C10101*1******00*C0LHLH*
v_outp[13]:C10101Z1ZZZLZZ00HC0LHLHH
v_errp[13]:                        
v_in [ 13]:110101*C0LHLH**00C
v_out[ 13]:110101ZC0LHLHHH00C
v_err[ 13]:

The 'I', 'H' and L' at the beginning of the lines have the following meaning:

This is really good news!

Michael

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 12, 2020, 24:52

The discussion on this page tells that they discovered the same problem.

Go figure. I'm a member of that forum but never know that discussion, thanks.
in the mean time i have more fresh tested vectors. 40192 and 40193 counters which are wrong in the database, the 40104 shift register and a LM339 which doesn't exists in the database. 

.40192 16
0LL11LLG001HH10V
0LH11LHG10KHH01V
1LH10LHG111LH01V
1LL11LLG111HH01V
1LL01LLG111HL01V
1LH11LHG111HH01V
.40193 16
0LL11LLG001HH10V
1HH11HHG11KHH01V
1HH10HHG111LH01V
1LL11LLG111HH01V
1LL01LLG111HL01V
1HH11HHG111HH01V
.40104 16
1100000G00CLLLLV
1111110G11CHHHHV
1111110G01CLHHHV
1111110G01CLLHHV
1111110G01CLLLHV
1111110G01CLLLLV
1111110G10CLLLHV
1111110G10CLLHHV
1111110G10CLHHHV
1111110G10CHHHHV
0111110G10CZZZZV
.LM339* 14
HHV01010101GHH
HHV01010110GLH
HHV01011001GHL
LHV01100101GHH
HLV10010101GHH
HHV01011010GLL
LHV01101001GHL
LLV10100101GHH
LHV01101010GLL
HLV10011010GLL
LLV10100110GLH
LLV10101001GHL
LLV10101010GLL

Anyway i will make a list of what i have tested so far.

When i use -W i get a failed test message:
Error: Chip failed logic test (11 test vectors failed) But the test is ok. :)

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 12, 2020, 01:28

I have tested some 4051 analog multiplexers. All went ok except for the last state in the test vector. When the Inhibit input is active the common output line should be in Z state. So here is the working test vector:

.4051 16
11L1100G0001011V
11L1100G0011101V
11L1100G0101110V
11L1100G0110111V
01L1100G1001111V
11L1000G1011111V
10L1100G1101111V
11L0100G1111111V
00H0000G0000100V
00H0000G0010010V
00H0000G0100001V
00H0000G0111100V
10H0000G1000000V
00H0100G1010000V
01H0000G1100000V
00H1000G1110000V
11Z1110G0001011V
DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 12, 2020, 01:51

When i use -W i get a failed test message:

Just found and fixed that one.

I moved the over-current avoidance logic to tl866iiplus_chiptest_setoutputs(). Unfortunately it is now a bit more complicated, but at least it works with the new test vectors from logic_test/lib/input/overcurrent_test.dat.

It is only needed for test vectors which make use switching between inputs and outputs or V and G.

I've added all of the test vectors you posted to testvectors3.dat and recreated the merged database.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 13, 2020, 12:02

A couple of test vectors:

.4018 16
011HHH1G10H1H00V
011LLL1G1CL1L00V
011HHH1G10H1H0CV
111HLH1G10H1HC0V
111LLH1G10H1HC0V
111LLL1G10H1HC0V
111LLL1G10L1HC0V
111LLL1G10L1LC0V
011LHL1G10L1LC0V
011HHL1G10L1LC0V
011HHH1G10L1LC0V
011HHH1G10H1LC0V
011HHH1G10H1HC0V
.4035 16
L1XX101G0000LLLV
H0XX101G0000HHHV
H1XX0C1G1111HHHV
L1XX0C1G0000LLLV
H1110C0G0000LLLV
H1110C0G0000LLHV
H1110C0G0000LHHV
H1110C0G0000HHHV
H1100C0G0000HHHV
L1000C0G0000HHHV
L1000C0G0000HHLV
L1000C0G0000HLLV
L1000C0G0000LLLV
.4054 16
C0LLLL0G0C0C0C0V
C0HHHH0G1C1C1C1V
01LLLL0G1010101V
.8212 24
K10L1H0L1H1G11L0H1L0H1HV
K11H0L1H0L1G11H1L0H1L0HV
000L0L0L0LKG11L0L0L0L0LV
001H1H1H1HKG11H1H1H1H1LV
111L1L1L1L1G1KL1L1L1L1HV
100Z0Z0Z0Z1G01Z0Z0Z0Z0HV
DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 13, 2020, 12:44

also added that test vectors.

It sounds you found no further bugs?

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 13, 2020, 14:14

Perhaps some untested chips in the database like the 4018 and 4035 above.

Also we have three old Intel chips in the database (8255, 8259 and 8279) which i think we should delete them. For example the 8259 interrupt controller will trigger an overcurrent protection . The problem with this chip is that it draws too much current (NMOS technology) and the ovc kicks in. Lowering the VCC a bit to 4.5V helps, but the test is not stable.

The -W flag really helped me a lot to debug some vectors.
But what really confused me is the X in a v_out vector when that pin is set to Z in v_in. That pin is an output and i just wanted to see its logic state (L or H). The chip is a CD4098 dual monostable and the pin is one of Q or /Q don't remember exactly. That pin should be L or H. So when reading back with pull-up then with pull-down we have a L state for a logic 0 and H for a logic 1 in both readings. When we have a 0 with pull-down read and 1 with pull-up read then that pin is in Z state. What an X means then? 

    7. now compare the defined result in the test vector with result_H and result_L:
      - if a bit is 0 in result_L and result_H the output is "0"
      - "  " "   "  1 "    "       "     "      "    "    "  "1"
      - if a bit is 0 in result_L and 1 and result_H the output is "Z"
      - error otherwise

What 'error otherwise' means?

The code in the logic.c is this:

  // check for Z-state in output
  strcpy(v_out, v_pullup);
  for(int j = 0; v_out[j]; j++)
  {
    if((v_out[j] == '1' || v_out[j] == '2' || v_out[j] == 'V')
      && (v_pulldown[j] == '0' || v_pulldown[j] == 'G'))
    {
        v_out[j] = 'Z';
    }
    else if(v_out[j] != v_pulldown[j]) {
      v_out[j] = 'X';
    }
  }

Thanks for all your work.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 13, 2020, 14:53

we have three old Intel chips in the database (8255, 8259 and 8279) which i think we should delete them

I changed the merge script to support a blacklist (logic_test/lib/input/blacklist.dat). For the blacklist chips, the pincount is set to 0:

.8255 0
.8259 0
.8279 0

That pin is an output an i just wanted to see its logic state (L or H)

When you use '*', then then value is read, but not checked. When you use 'Z' you will get an error when the output is not 'Z'.

When we have a 0 with pull-down read and 1 with pull-up read then that pin is in Z state. What an X means then?

That is one of the cases where a developer normally writes this comment in the code: "that case can never happen in real life" :-)

'X' means with pull-up the readback value was '0' and with a pull-down the readback was '1', that means the pin has changed its output between the two readings but inverted to the 'Z' state.

That can happen in 2 cases:

  1. the output is independent from the input (e.g. just a clock)
  2. another input pin is being used as output instead of input in the test vector and the applied pullup/pulldown causes the first pin to change its state. You never should try to read back an input pin.

For example: Y = ! A

When using Y and A as output (e.g. with 'H', 'L', 'Z' or '*'), then applying pull-up to A results in '0' to Y and pull-down results in '1' which would explain what you see.

Michael

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 13, 2020, 16:19

When you use '*', then then value is read, but not checked. When you use 'Z' you will get an error when the output is not 'Z'.

This is what i really want. To see the output pins as errors for debugging purpose. I use this trick temporary only to see output values in v_err; for example a walking zero in a shift register with outputs printed in v_err. It helps me visually. Something like this:

v_in [  1]:LH001LHGHL100HLV
v_out[  1]:ZZ001ZZGZZ100ZZV
v_err[  1]:LL   LL LL   LH

'X' means with pull-up the readback value was '0' and with a pull-down the readback was '1', that means the pin has changed its output between the two readings but inverted to the 'Z' state.

Yes, i knew the answer but i wanted to be sure.

the output is independent from the input (e.g. just a clock)

Hmm, check this:
4098

We have two monostable here in a single DIP16 package. The left side device (pin 1 to 6) and the right side device (pin 9 to 15). We test both sections at the same time.

First test vector is this:

v_in [ 1]:XZ001ZZGZZ100HXV

Reset is logic 0 active. TR+=0 And TR-=1 (both in inactive state).
the output is ok:

v_out[  1]:LH001LHGHL100HLV
v_err[  1]: H   LH HL   H

Q1=Q2=L ; /Q2=/Q2=H ; RXCX1=RXCX2=H. This is the reset state, all ok.

Now lift the reset pins to logic 1 (pin 3 and 13)

v_in [  2]:XZ101ZZGZZ101ZXV
v_out[  2]:LH101LHGHL101HLV
v_err[  2]: H   LH HL   H

Nice. The monostable keeps the previous state. This is the wait(stable) state.
Now let's trigger both monostables via TR+ pin (pin 4 and 12, logic 1 active):

v_in [  3]:XZ111ZZGZZ111ZXV
v_out[  3]:LZ111XZGZX111ZLV
v_err[  3]:     X   X

Bam!
Q=X, /Q=Z (both monostables). The RXCX pins switches to Z state.
Is this an error or what. A possible reason for this is the RXCX pin connected to VCC thru a pull-up resistor and the parasitic capacitance of the same pin to the ground will count as a real capacitor. In this condition a short pulse will be generated and we will get this 'issue'.
I should put a scope to see if i can capture this.

Should we introduce the 4098 in the database as is? i mean in this particular case the 'X' means a generated pulse? How we should check this? we can check for L/H/Z states or no check with * but how to check for an X or pulse?
Or maybe we should avoid monostables?

Thanks for clarifications!

Later edit. I was right, a pulse is generated when TR+ or TR- inputs are triggered: cap
Channel-1 is the Q1 output and the channel-2 is the TR+ input. The pulse width generated is 7ms. Now all is clear with that 'X'.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 13, 2020, 19:12

Found a bug. No chip inserted.

minipro  -T -p "4001"
Found TL866II+ 04.2.115 (0x273)
VCC=5V
v_in [  1]:00HH00G00HH00V
v_out[  1]:00ZZ00G00ZZ00V
v_err[  1]:  ZZ     ZZ

v_in [  2]:01LL01G01LL01V
v_out[  2]:01ZZ01G01ZZ01V
v_err[  2]:  ZZ     ZZ

v_in [  3]:10LL10G10LL10V
v_out[  3]:10ZZ10G10ZZ10V
v_err[  3]:  ZZ     ZZ

v_in [  4]:11LL11G11LL11V
v_out[  4]:11ZZ11G11ZZ11V
v_err[  4]:  ZZ     ZZ

Error: Chip failed logic test (4 test vectors failed)

Then with -W flag:

minipro -W -T -p "4001"
Found TL866II+ 04.2.115 (0x273)
VCC=5V
v_in [  1]:00HH00G00HH00V
v_out[  1]:00ZZ00G00ZZ00V
v_err[  1]:  ZZ     ZZ

v_in [  2]:01LL01G01LL01V
v_out[  2]:01ZZ01G01ZZ01V
v_err[  2]:  ZZ     ZZ

v_in [  3]:10LL10G10LL10V
v_out[  3]:10ZZ10G10ZZ10V
v_err[  3]:  ZZ     ZZ

v_in [  4]:11LL11G11LL11V
v_out[  4]:11ZZ11G11ZZ11V
v_err[  4]:  ZZ     ZZ

Chip passed logic test

So the -W will override the success status.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 14, 2020, 05:49

Any non-steady behavior cannot be checked reliably, because we don't have a real-time system and can not guarantee exact timing. That could be done in the firmware of the TL866 but not with bit-banging from the PC.

Therefore I would remove the 4098 from the database. I also added all other monostable and all multivibrators and VCOs to the blacklist (according to wikipedia). The only one we had in the test database was the 74123, so this is not a big problem.

I have changed the behaviour of 'X' in the test vector, because the original meaning in WinCUPL is "untested". It will not longer apply the pull-up/pull-down, but it will leave the pin in floating state. This will avoid the behavior described in my previous comment when 'X' was used for input. Hopefully this doesn't break anything else.

@radiomanV: What do you think about this?

Instead of floating I could also use either pulldown or pullup, but switching between those is not a good idea. Using 'X' for inputs is not a good idea, it should be only used for NC.

In JEDEC the meaning of 'X' is "Output not tested, input default level", but that definition is bullshit because it assumes that I know if a pin is an input or output and could act accordingly.

The beaviour of '' will not be changed and use pullup/pulldown to read the value because its meaning in WinCUPL is "simulator determined*".

In the database I was looking for some examples which use 'X'. Most of them use it for NC pins. The 7448 is using 'X' for the states where the truth table has an 'X'.

So the -W will override the success status

fixed.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 14, 2020, 13:15

Therefore I would remove the 4098 from the database. I also added all other monostable and all multivibrators and VCOs to the blacklist (according to wikipedia). The only one we had in the test database was the 74123, so this is not a big problem.

I totally agree. We cannot reliably test monostables (i tested 74121 and others).

I have changed the behaviour of 'X' in the test vector, because the original meaning in WinCUPL is "untested". It will not longer apply the pull-up/pull-down, but it will leave the pin in floating state. This will avoid the behavior described in my previous comment when 'X' was used for input. Hopefully this doesn't break anything else.

@radiomanV: What do you think about this?

Should be ok. In fact unlike the TL866A/CS there's no floating state for TL866II+. If you disable a pull-down resistor (about 39K) then that line will automatically lift to VDD (pull-up). A pin state after reset or TL866IIPLUS_RESET_PIN_DRIVERS is input with pull-down resistor activated.

If you do the following sequence:

If you do:

So no floating state at all.

Moreover if you enable pull-ups/downs like this:

Another sequence:

So the order in which we enable/disable pull-ups/downs is important. From what i see in tl866iiplus_chiptest_setoutputs the order is correct (the pull-down is disabled after the pull-up is enabled). This ensures that pull-down is really disabled.
So there are some interlocks in firmware. We can have only pull-up enabled, only pull-down enabled, both pull-up and pull-down enabled but never both disabled.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 14, 2020, 15:30

but never both disabled.

Then the natural choice for TTL chips is to use a pull-up for unused pins ('X'), because that is the behavior of an open TTL input.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 14, 2020, 16:23

because that is the behavior of an open TTL input.

Indeed an open TTL input count as logic 1. But not for CMOS devices. Unused 'X' means not used in test not NC. IMO you can leave it with the default pull-down (the 12K pull-down is too weak for a TTL chip input, but for a CMOS device input this is definitely a logic 0) or if you really want set the pull-up (and disable the pull-down after).

Right now i'm testing some 74HCT390 (Dual decade ripple counter) pulled from an old home made frequency counter. I have random errors at Q1 output of counter no. 1 (L instead of H or vice versa). If i increase the VCC then the test is OK. Also lowering the VCC voltage has same effect. Only when i set the VCC to 5V or 5.5V i have random errors. The XGPRO software test is ok.
I tried to revert some commits and same result. Perhaps i should play with the test vector a bit.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 15, 2020, 24:43

74HCT390: I have random errors at Q1 output of counter no. 1

The internet says about 74HCT: "Inputs have very high impedance (resistance), this is good because it means they will not affect the part of the circuit where they are connected. However, it also means that unconnected inputs can easily pick up electrical noise and rapidly change between high and low states in an unpredictable way."

Sounds like we have glitches on the clock line. Maybe switching the clock line is not clean enough, e.g. there is a floating stage when switching between 0 and 1. It might be a good idea to enable the pull-downs for the GND and 1 states so the transition is more smooth.

I now always enable the pull-down, except for the pull-up state, can you please check if this helps?

Could you try to use 'V' instead of '1' for the 1MR and 2MR pins in the test vectors?

At which test vector number do you get the error, at the beginning or at random vector numbers? Can you post the output?

You can also try to put a capacitor between the power lines of the chip.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 15, 2020, 05:14

Sounds like we have glitches on the clock line. Maybe switching the clock line is not clean enough, e.g. there is a floating stage when switching between 0 and 1.

First i thought the same but nope.

This is the clock line (pin 1, CP0): HCT390_Clock
Looks clean to me despite that is not at the correct polarity for this chip.
This is the first CMOS chip with this issue and i tested plenty of CMOS counters/flip-flops/shift registers and no issue. Just this chip.

Also: HCT390_Cap1
Channel 1 is the clock (pin1) and channel2 (blue) is the Q1 output (pin3). A very steady logic 0 :) 

VCC=5V
v_in [  1]:01X0XXXGXXX0X10V
v_out[  1]:01L0LLLGLLL0L10V
v_err[  1]:

v_in [  2]:00L0LLLGLLL0L00V
v_out[  2]:00L0LLLGLLL0L00V
v_err[  2]:

v_in [  3]:C0H1LLLGLLL1H0CV
v_out[  3]:C0L1LLLGLLL1H0CV
v_err[  3]:  L

v_in [  4]:C0L0HLLGLLH0L0CV
v_out[  4]:C0L0HLLGLLH0L0CV
v_err[  4]:

v_in [  5]:C0H1HLLGLLH1H0CV
v_out[  5]:C0L1HLLGLLH1H0CV
v_err[  5]:  L

v_in [  6]:C0L0LHLGLHL0L0CV
v_out[  6]:C0L0LHLGLHL0L0CV
v_err[  6]:

v_in [  7]:C0H1LHLGLHL1H0CV
v_out[  7]:C0L1LHLGLHL1H0CV
v_err[  7]:  L

v_in [  8]:C0L0HHLGLHH0L0CV
v_out[  8]:C0L0HHLGLHH0L0CV
v_err[  8]:

v_in [  9]:C0H1HHLGLHH1H0CV
v_out[  9]:C0L1HHLGLHH1H0CV
v_err[  9]:  L

v_in [ 10]:C0L0LLHGHLL0L0CV
v_out[ 10]:C0L0LLHGHLL0L0CV
v_err[ 10]:

v_in [ 11]:C0H1LLHGHLL1H0CV
v_out[ 11]:C0L1LLHGHLL1H0CV
v_err[ 11]:  L

v_in [ 12]:C0L0LLLGLLL0L0CV
v_out[ 12]:C0L0LLLGLLL0L0CV
v_err[ 12]:

Error: Chip failed logic test (5 test vectors failed)

The test vector is ok. The first two lines is the reset then a clock ('C') is applied to the clock line. The pin 3 (Q1) should toggle with each clock pulse. Tried with reversed clock (K) no change.

You can also try to put a capacitor between the power lines of the chip.

A decoupling capacitor has no effect.

Increasing the VCC to 6.5V:
HCT390_Cap2 

VCC=6.5V
v_in [  1]:01X0XXXGXXX0X10V
v_out[  1]:01L0LLLGLLL0L10V
v_err[  1]:

v_in [  2]:00L0LLLGLLL0L00V
v_out[  2]:00L0LLLGLLL0L00V
v_err[  2]:

v_in [  3]:C0H1LLLGLLL1H0CV
v_out[  3]:C0H1LLLGLLL1H0CV
v_err[  3]:

v_in [  4]:C0L0HLLGLLH0L0CV
v_out[  4]:C0L0HLLGLLH0L0CV
v_err[  4]:

v_in [  5]:C0H1HLLGLLH1H0CV
v_out[  5]:C0H1HLLGLLH1H0CV
v_err[  5]:

v_in [  6]:C0L0LHLGLHL0L0CV
v_out[  6]:C0L0LHLGLHL0L0CV
v_err[  6]:

v_in [  7]:C0H1LHLGLHL1H0CV
v_out[  7]:C0H1LHLGLHL1H0CV
v_err[  7]:

v_in [  8]:C0L0HHLGLHH0L0CV
v_out[  8]:C0L0HHLGLHH0L0CV
v_err[  8]:

v_in [  9]:C0H1HHLGLHH1H0CV
v_out[  9]:C0H1HHLGLHH1H0CV
v_err[  9]:

v_in [ 10]:C0L0LLHGHLL0L0CV
v_out[ 10]:C0L0LLHGHLL0L0CV
v_err[ 10]:

v_in [ 11]:C0H1LLHGHLL1H0CV
v_out[ 11]:C0H1LLHGHLL1H0CV
v_err[ 11]:

v_in [ 12]:C0L0LLLGLLL0L0CV
v_out[ 12]:C0L0LLLGLLL0L0CV
v_err[ 12]:

Chip passed logic test

Lowering the VCC to 3.3V also works. VCC=4V/4.5V/5V no. Strange!

If i put a resistor about <5K btetween the clock line and ground the issue is curred and i can test the chip at any VCC voltage.

Could you try to use 'V' instead of '1' for the 1MR and 2MR pins in the test vectors?

No effect.

Also just for fun the CP1 input of the :5 counter works ok no matter what VCC i use or clock polarity (C or K). So the code is ok.
HCT390

This is something about with logic 0/1 voltage levels.

Wikipedia:

HCT stands for high-speed CMOS with transistor–transistor logic voltages. These devices are similar to the HCMOS types except they will operate at standard TTL power supply voltages and logic input levels. This allows for direct pin-to-pin compatible CMOS replacements to reduce power consumption without loss of speed.

hct
Yet, if i comment this:

      if(tl866iiplus_pin_set_bit(gnd_pins, sizeof(gnd_pins)/sizeof(gnd_pins[0]), msg_gnd_s, zif_pin)) {
        if(s == 'G') {
          ret = EXIT_FAILURE;
          fprintf(stderr, "Error: Device pin %d (zif pin %d) cannot be set to 'G'\n", dut_pin, zif_pin);
        }
        else { // don't fail for '0'
          fprintf(stderr, "Warning: Device pin %d (zif pin %d) cannot be set to strong '0', using weak '0'\n", dut_pin, zif_pin);
        }
      }

Test will pass. Some HCMOS devices don't like the logic '0' to be under 0.8V (strange).
This means that we need a switch to enable/disable the strong logic 0.
I'll need more HC/HCT chips to test.

Later edit:
Tested some SN74HCT138, SN74HC32, SN74HCT00, SN74HCT32, SN74HCT273, CD74HCT08, CD74HC00, CD4543, SN74LS393, 74HC02. All went ok.

According to the specs for CD74HCT390 at VCC=4.5V logic 0 should be gnd to max 0.5 and logic 1 vcc to min 3.15 so we are in specs, wtf.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 15, 2020, 22:44

Yet, if i comment this: (use strong G)

I don't think it is the voltage of 'G', I think we have 2 falling edges very fast one after the other with an open input in between and that's why your 5k pull-down helps. The pulse might be very short (e.g. <<0.1us), but the clock line would still catch it. To test that you could connect the output of the /2 divider to the clock input of the /5 divider.

USB commands when changing from '1' to 'G':

  1. SET_DIR OUT // should not be a change, is already OUT
  2. SET_OUT 0
  3. SET_GND 1

USB commands when changing from 'G' to '1':

  1. SET_DIR OUT // should not be a change, is already OUT
  2. SET_OUT 1
  3. SET_GND 0 (clear phase)

Actually each sequence is executed twice for reading with pull-up and with pull-downs, but there should not be a change of the values.

A USB command should take at least 1ms (minimum poll time for full-speed USB) and when each of the commands is immediately applied, the suspicious edges would be apart 1ms.

What I also don't understand is the timing: the clock pulses shall be 5ms wide because I use usleep(5000) after each call to minipro_chiptest_setoutputs(). The total length of a clock pulse should be 3x5ms + the time for the USB commands, but it is less than half of that.

Can you zoom into a single clock pulse, especially into the edges and 1ms after/before each edge?

Let's summarize what we have:

  1. Depends on the pin1; ok with both /5 dividers and also the other /2 divider
  2. Depends on Vcc
  3. Depends on driving the pin low with G instead of just 0
  4. A pull-down (<5k) cures the problem
  5. Either we have no falling edge or a multiple of 2 with very short glitches

A possible workaround or test could be to insert the chip starting a pin 2 and shift the test vectors by one pin (add 'X' at beginning and end of test vectors). At least we would know then that it is a problem with pin 1.

Hopefully I can get a 74HCT390 today, but we only have a small electronics shop here.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 15, 2020, 23:48

A possible workaround or test could be to insert the chip starting a pin 2 and shift the test vectors by one pin (add 'X' at beginning and end of test vectors). At least we would know then that it is a problem with pin 1.

This is it. Shifting the chip down one position cured this issue.

This is the test vector:

.74390 18
X01X0XXXGXXX0X10VX
X00L0LLLGLLL0L00VX
XC0H1LLLGLLL1H0CVX
XC0L0HLLGLLH0L0CVX
XC0H1HLLGLLH1H0CVX
XC0L0LHLGLHL0L0CVX
XC0H1LHLGLHL1H0CVX
XC0L0HHLGLHH0L0CVX
XC0H1HHLGLHH1H0CVX
XC0L0LLHGHLL0L0CVX
XC0H1LLHGHLL1H0CVX
XC0L0LLLGLLL0L0CVX

And the result:

VCC=5V
v_in [  1]:X01X0XXXGXXX0X10VX
v_out[  1]:H01L0LLLGLLL0L10VH
v_err[  1]:

v_in [  2]:X00L0LLLGLLL0L00VX
v_out[  2]:H00L0LLLGLLL0L00VH
v_err[  2]:

v_in [  3]:XC0H1LLLGLLL1H0CVX
v_out[  3]:HC0H1LLLGLLL1H0CVH
v_err[  3]:

v_in [  4]:XC0L0HLLGLLH0L0CVX
v_out[  4]:HC0L0HLLGLLH0L0CVH
v_err[  4]:

v_in [  5]:XC0H1HLLGLLH1H0CVX
v_out[  5]:HC0H1HLLGLLH1H0CVH
v_err[  5]:

v_in [  6]:XC0L0LHLGLHL0L0CVX
v_out[  6]:HC0L0LHLGLHL0L0CVH
v_err[  6]:

v_in [  7]:XC0H1LHLGLHL1H0CVX
v_out[  7]:HC0H1LHLGLHL1H0CVH
v_err[  7]:

v_in [  8]:XC0L0HHLGLHH0L0CVX
v_out[  8]:HC0L0HHLGLHH0L0CVH
v_err[  8]:

v_in [  9]:XC0H1HHLGLHH1H0CVX
v_out[  9]:HC0H1HHLGLHH1H0CVH
v_err[  9]:

v_in [ 10]:XC0L0LLHGHLL0L0CVX
v_out[ 10]:HC0L0LLHGHLL0L0CVH
v_err[ 10]:

v_in [ 11]:XC0H1LLHGHLL1H0CVX
v_out[ 11]:HC0H1LLHGHLL1H0CVH
v_err[ 11]:

v_in [ 12]:XC0L0LLLGLLL0L0CVX
v_out[ 12]:HC0L0LLLGLLL0L0CVH
v_err[ 12]:

Chip passed logic test

There's something with pin 1, yet the XGpro test is ok. Thanks, i'll do more tests this evening.

DavidGriffith commented 4 years ago

In GitLab by @michael.dreher42 on Jul 16, 2020, 04:06

I hooked up my scope to compare pins 1 and 2, but without a real chip.

  1. The only difference between the pins is that pin 1 goes low 370ns before pin 2.
  2. With a 1k resistor against GND, the high voltage drops down from 3.3V to 2.1V for both pins. That would be pretty close to the low limit of HIGH (according to https://www.ti.com/lit/an/scla011/scla011.pdf?ts=1594896711549&ref_url=https%253A%252F%252Fwww.google.com%252F, figure 3),
    but your scope picture shows a HIGH voltage around 3.3V, so that should no be the problem here.
  3. When pin 1 switches from 1 to 0, there is a small glitch on pin 2 (+-0.14V).
  4. When pin 2 switches from 1 to 0, there is a small glitch on pin 1 (+-0.14V), that means the voltage gets negative to -0.14V.

I couldn't find any good reason why it shouldn't work.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 16, 2020, 05:16

We are in specs Michael, leave it alone. I forgot to say, but yesterday while digging for a fix i tried some capacitors (100pF-470nF) on pin 1 to ground (the idea was to cut short pulses/glitches) but no effect.

I think this is something with QC, i'll try a good clean with IPA because this issue manifests randomly.
I mean the test is running ok then after some time suddenly begin to fail or after some time of not working starts to work.

I think that i should check the NPN transistor on the GND1 because if i remove the code which manipulate this transistor or i use XGPro (XGpro doesn't use GND strong 0 driver) then it works. Could be afflicted by something... :) I'll make some investigations when i get home this evening. Thanks for your help.

DavidGriffith commented 4 years ago

In GitLab by @radiomanV on Jul 16, 2020, 23:42

I couldn't find any good reason why it shouldn't work.

Good news. After cleaning my boards with IPA the random isue with pin 1 driver is cured. And to be sure i replaced the GND1 NPN transistor. Perhaps this was not necessary but well...

However i did more tests. Enabled Pull-ups on ZIF1 and ZIF2 and disabled pull-downs then in a while loop toggled GND1 and GND 2. I/O lines were configured as inputs. My old Hameg scope captured this (pin1=red, pin2=blue):

Disable GND transistors, transition from 0 to 1: GND1_1
Nice, we have a 3.5uS rise time.

Enable GND transistors, transition from 1 to 0:
GND1_3
This sucks but this is a natural line ringing.

Fortunately we don't use only a strong 0 to drive an output line like this, but we must ensure the order in which we set the I/O line and GND strong 0.

If we set first the GND and then I/O to 0 then the line is ringing like hell (see capture above).
If we first set the I/O to 0 and then the GND strong 0 we have this: GND1_4
A nice fall without oscilations. From what i see in the code this is our case.

What I also don't understand is the timing: the clock pulses shall be 5ms wide because I use usleep(5000) after each call to minipro_chiptest_setoutputs(). The total length of a clock pulse should be 3x5ms + the time for the USB commands, but it is less than half of that.

This code:

while(1){
  msg_gnd[gnd_pins[GND1].byte] |= gnd_pins[GND1].mask;
  msg_gnd[gnd_pins[GND2].byte] |= gnd_pins[GND2].mask;
  msg_out[8]= 0;
  msg_out[9] = 0;
  if (msg_send(handle->usb_handle, msg_out, sizeof(msg_out))) {
    return EXIT_FAILURE;
  }
  if (msg_send(handle->usb_handle, msg_gnd, sizeof(msg_gnd))) {
    return EXIT_FAILURE;
  }
  msg_gnd[gnd_pins[GND1].byte] = 0;
  msg_gnd[gnd_pins[GND2].byte] = 0;
  msg_out[8]= 1;
  msg_out[9] = 1;
  if (msg_send(handle->usb_handle, msg_out, sizeof(msg_out))) {
    return EXIT_FAILURE;
  }
  if (msg_send(handle->usb_handle, msg_gnd, sizeof(msg_gnd))) {
    return EXIT_FAILURE;
  }
       }

Produce this waveform: GND1_Clock
The logic 1 width is 60uS :)

So, afterall the HCT390 test vector and code are ok.

DavidGriffith commented 4 years ago

In GitLab by @lychaxo on Nov 5, 2020, 20:22

@michael.dreher42 I've had great luck with your logic_test branch. I did want to contribute vectors I made for testing 7483s, since those weren't in your tree. This will generate every possible vector (probably a subset of these would be sufficient to ensure full function and be faster -- this takes a few seconds to test with my TL866ii!); runs under Slackware64-current (e.g. GNU coreutils 8.32, GNU bc 1.07.1, bash 5.0.017) fine, probably other distros as well:

#!/bin/bash
(
  echo .7483 16
  for a in {0..15} ; do ba=$(printf "'Reference to deleted milestone 4's" `echo "obase=2;$a"|bc -q`|tr ' ' 0) ; for b in {0..15} ; do bb=$(printf "'Reference to deleted milestone 4's" `echo "obase=2;$b"|bc -q`|tr ' ' 0) ; for c0 in 0 1 ; do s=$(printf "'Reference to deleted milestone 5's" `bc <<< "obase=2;$a+$b+$c0"`|tr ' 01' LLH) ; a4=`cut -c1 <<<$ba` ; a3=`cut -c2 <<<$ba`; a2=`cut -c3 <<<$ba` ; a1=`cut -c4 <<<$ba` ; b4=`cut -c1 <<<$bb` ; b3=`cut -c2 <<<$bb` ; b2=`cut -c3 <<<$bb` ; b1=`cut -c4 <<<$bb` ; c4=`cut -c1 <<<$s` ; s4=`cut -c2 <<<$s` ; s3=`cut -c3 <<<$s` ; s2=`cut -c4 <<<$s` ; s1=`cut -c5 <<<$s` ; echo $a4$s3$a3${b3}V$s2$b2$a2$s1$a1${b1}G$c0$c4$s4$b4 ; done ; done ; done
) > 7483-vectors.dat

There may be a more clever set of test vectors out there in some other package already (but then reproducing them might be legally iffy ground). Here's the output, xz'd and mimencoded:

/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4CIIAjNdABcNwtQe/6rTSHkrAABfMAfhNjdlvc9y
lqR2C0OHGDbWxYrwl8pje4F1OHfTU42ylZ5KOlyDIzjvC0C4R9z0y4qZy48kD+I8ad8kZ0d5
aJKPCtRXR2QtpF2a4UCMrrU1EW+FW+a4Qf4wIBNjK4YJbzKiyK6T8AbsfO1XkJRNs2xayG6B
AUzUURnUmvhrbMY9JUatqV4QoK/dh4kvpP0v2YXRfVQKCnv9htDUk95DcxuqtPRc7WHGPcrY
vFctJf5u/mP0AA7hp7qoDQPy6MIA5vztlM6xEN5IWM28Dx/TUcoooRru1PWq6boY/q0dXvw9
LcZu2GM17ySe6iiYlTdBtjpsp+bS8NWk8ClnJRX/oKrC1cGyVVVIUqIoOifRO1PZBj+Gs0Nc
wXp/zNJhsC3sN21GY36JF6+BQhAALMyJXH1RFToqYwowWOMif1UkgG040TTw4L4V9VQhMCiX
4598kWQvyFy9o1kv4LYe4yfngoLNdU2YFjSAdCpNXFI6QZ2mmloJniV+Mz2X3A6HUoZdUf37
d5C1PffNEAKAjttwA6+wu9Jtmoe860hYObFbHu4l3eJxWKrKLe5k1NTbbYEnXt809oDJiZOv
U3xFz+Gszpj8IVUH6tPM2uMB/WIwRYkVqBvxSKnMVza+kPd0dgXkLVcS4BTOJeieMwTfbcCi
MiOZIJU8fLKh+Al1CnmkSpXFWgbVvHoAvs+VsbBGUNRUzCye6/vNyrcLMmVeBWne7QEcacFT
AAA+/VEWuBkjkQABzwSJRAAA0QKpMbHEZ/sCAAAAAARZWg==

I hope this is useful, I apologize in advance if it is not.

DavidGriffith commented 3 years ago

In GitLab by @S0urceror on Jun 15, 2021, 13:52

@michael.dreher42, I have just tested your branch and it works splendidly. The other branch that was proposed with new firmware commands looks great but has some flaws. I am now trying testing my custom IC with your version. Thanks and I hope this gets merged.

DavidGriffith commented 3 years ago

In GitLab by @retiredfeline on Oct 3, 2021, 06:44

Hi, exciting feature, thanks for the great work. I did a clone and compiled, hoping to test a 74LS373. Unfortunately I discovered that this feature is only for the II and I have a CS. Is there any plan to make it work for the A/CS? (I would have tried testing with the Minipro software, but USB forwarding stopped working for my VirtualBox Windows XT instance.)