Skip to content

ATF22LV10CZ

I have ended up with a bunch of ATF22LV10CZ-25PC chips for some reason. They are supposed to be equivalent to ATF22V10CZ except for the Vcc range of 3.0-5.5V. I have tried to program them with both minipro and Xgecu's official software 10.31 (2020-08-19, so extremely new.)

This is with TL866II+ and the firmware version is 04.2.118. I'm using minipro 0.4-73-g7a2f4c78f462 from the master branch. The .jed file is compiled with WinCUPL in "g22v10" (GAL22V10 compatible mode.)

They seem to program with Xgecu's software in ATF22V10CZ mode, but in minipro I get:


[hpa@carbon-x1 git]$ minipro -p ATF22V10CZ -w abc80-1m-ic4.jed Found TL866II+ 04.2.118 (0x276)

VPP=12V Warning! JED file doesn't match the selected device!

Declared fuse checksum: 0xE583 Calculated: 0xE583 ... OK Declared file checksum: 0x94C7 Calculated: 0x94C7 ... OK JED file parsed OK

Use -P to skip write protect

Erasing... 0.33Sec OK Writing jedec file... 5.01Sec OK Reading device... 0.32Sec OK Writing lock bit... 0.35Sec OK Verification failed at address 0x16C6: File=0x01, Device=0x00

0x16C6 is 5830, and in PAL mode this chip is documented to have 5828 fuses, so that is likely to be the culprit.


In 'ATF22V10CZ(UES)' mode, which according to the datasheet ought to be the correct mode it segfaults:

[hpa@carbon-x1 git]$ gdb --args which minipro -p 'ATF22V10CZ(UES)' -w abc80-1m-ic4.jed GNU gdb (GDB) Fedora 9.1-6.fc32 [...] (gdb) run Starting program: /usr/local/bin/minipro -p ATF22V10CZ(UES) -w abc80-1m-ic4.jed [...] Found TL866II+ 04.2.118 (0x276)

VPP=12V Declared fuse checksum: 0xE583 Calculated: 0xE583 ... OK Declared file checksum: 0x94C7 Calculated: 0x94C7 ... OK JED file parsed OK

Use -P to skip write protect

Erasing... 0.33Sec OK

Thread 1 "minipro" received signal SIGSEGV, Segmentation fault. 0x0000000000410f0a in write_jedec (handle=0x4202a0, jedec=0x7fffffffcac0) at main.c:1188 1188 for (i = 0; i < config->fuses_size; i++) { [...] (gdb) p *config Cannot access memory at address 0x0


Please let me know if there is any way I can assist with debugging this. I'm more than willing to risk the devices, so if they break they break.

-hpa