"Write PES" and "Erase All" issues with 22V10

[ceteras]

I've found a few issues while working with a Lattice GAL22V10D which had its PES erased (10 FFs).
Replicating the issues will have to start with a completely erased chip.

Steps I followed are:

1. attempt to write a new PES:

./afterburner_osx -d /dev/tty.usbmodem101 p -v -t GAL22V10 -nc -pes "00:05:49:A1:CD:A4:03:00"

I took the PES from another chip.

This would send data in the wrong place in the chip, the result looks like this:

L5720 11111111111111111111111111111111111111111111*
L5764 11111111111111111111111111111111111111111111*
L5808 10101100000000000000*
N UES FF FF FF FF FF FF FF FF*
L5828 1111111111111111111111111111111111111111111111111111111111111111*
N PES FF FF FF FF FF FF FF FF FF FF*
CDB57

Line starting at 5808 was affected.
I fixed this by treating GAL22V10 similarly to GAL6001/2:
In writePes() function I've added a case to switch(gal)

    case GAL22V10:
      setRow(0);
      for (rbit = 0; rbit < 64; rbit++) {
        b = pes[rbit >> 3];
        p = b & (1 << (rbit & 0b111));
        sendBit(p);
      }
      sendBits(52, 0);
      sendAddress(6, galinfo.pesrow);
      setSDIN(0);
      break;

Using info from http://www.armory.com/%7Erstevew/Public/Pgmrs/GAL/algo.htm I tried adding the 52 L bits.

This caused the data to be sent to the proper row in the chip, but because the PES sent was 8 bytes not 10 as 22V10 requires, the data was shifted two bytes to the right:

L5764 11111111111111111111111111111111111111111111*
L5808 11111111111111111111*
N UES FF FF FF FF FF FF FF FF*
L5828 1111111111111111111111111111111111111111111111111111111111111111*
N PES 00 00 00 05 49 A1 CD A4 03 00*
CDD2F

2. attempt to erase the wrong PES
   The erase with -all argument does not execute if a chip cannot be identified (-nc is required if you have a bad PES).

I've changed the check in afterburner.c in main:

if (opErase /*&& 0 == result*/) {
         result = operationEraseGal();
     }

Another issue seems to be the Erase All row address, in galInfoList[] I've set the eraseallrow to 57 for GAL22V10 (value taken from the same web page above).
I was able to erase the bad PES value.

3. Hack to shift the PES to its correct location
   As we can only send 8 bytes for PES, I've changed the number of L bits sent from 52 to 68 :

    case GAL22V10:
      setRow(0);
      for (rbit = 0; rbit < 64; rbit++) {
        b = pes[rbit >> 3];
        p = b & (1 << (rbit & 0b111));
        sendBit(p);
      }
      sendBits(68, 0);
      sendAddress(6, galinfo.pesrow);
      setSDIN(0);
      break;

After these hacks I could have a proper PES written in my chip:

L5720 11111111111111111111111111111111111111111111*
L5764 11111111111111111111111111111111111111111111*
L5808 11111111111111111111*
N UES FF FF FF FF FF FF FF FF*
L5828 1111111111111111111111111111111111111111111111111111111111111111*
N PES 00 05 49 A1 CD A4 03 00 00 00*
CDD2F

... and identify it:

./afterburner_osx -d /dev/tty.usbmodem101 i -t GAL22V10   
PES info: 5V Lattice GAL22V10  VPP=13.0 Timing: prog=40 erase=25

[ole00]

Thanks for the research and for sharing the information along with your code snippets. I have some GAL22V10D and GAL22V10B available, so will check your solution on both chips and update the code soon.

[ole00]

BTW. How did you find out you need to change the number of bits from 52 to 68 in "sendBits(68, 0);" ? Experimentally? Or have you found any note regarding this ? The link on the armory.com documentation mentions 80 bits for PES data on GAL22V10. Thanks.

[ceteras]

The armory page mentions 52 bits, and I needed two extra bytes for the PES (I've sent an 8 byte argument as it's the only accepted length).
The 16 extra bits compensate for the PES argument not being 10 bytes long, and are actually part of the PES, in the end.
I was lucky that the last 3 bytes in the PES are all zeroes.
If you change the pc app to accept 10 bytes PES, then for 22V10 only 52 low bits are needed.

[ceteras]

Another issue I've found related to bad PES in the chip: when you want to read the chip and your PES is bad, you have to use the "-nc" flag, and this means the pes variable will not be initialized with the actual wrong value in the chip, but with 12 zeroes (by case COMMAND_DISABLE_CHECK_TYPE).
So printJedec() will print zeroes for the PES section, and we cannot see the actual values stored .

My workaround was to add a call to readpes() in printJedec() function:

    readPes();
    Serial.print(F("N PES"));

Perhaps a better solution would be to call readpes() there:

      case COMMAND_DISABLE_CHECK_TYPE: {
        readPes();
        setFlagBit(FLAG_BIT_TYPE_CHECK, 0);
      } break;

[ole00]

Thanks again for the fix. I've tested the fix on my GAL22V10D and GAL22V10B. I had to also fix 'erase all' command which was not working on GAL22V10 and was preventing me to erase PES. Both of them (erase PES and write PES) now work fine. I've also committed the changes.

[ole00]

Related to missing PES on your GAL26CV12, I've tested erasing and writing a new PES on my GAL26V12 (without C) and PES writing did not work. I tried to mod the source code you described above to work for GAL26V12 and it did the trick. I was wondering whether you could try it on your GAL26CV12 ? Thanks. The fix is in writePes() in the Arduino sketch:

    case GAL22V10:
    case GAL26V12:
    case GAL26CV12:
      setRow(0);
      for (rbit = 0; rbit < 64; rbit++) {
        b = pes[rbit >> 3];
        p = b & (1 << (rbit & 0b111));
        sendBit(p);
      }
      sendBits(GAL22V10 == gal ? 68 : 86, 0);
      sendAddress(6, galinfo.pesrow);
      setSDIN(0);
      break;

Perhaps you could fix your GAL26CV12 by writing the following PES:
00:05:58:A1:4D:A5:03:00

Let me know whether that worked for you. Thanks.

[ceteras]

Thank you, I'll give it a try!

[ceteras]

It didn't work for my chips, however I don't trust the source I've got them from.
I'm waiting for an order of 4x 26CV12 from another seller, I'll let you know how that works.

Question, why the 86 for the GAL26 ?

PES: RA=0: b0..b95, 26*L, L, H, L, H, H, H (96+26+6 bit, line 58)
That is 128 bits in total.
So, 64bits PES, 86 bits L, 6 bits addres is 156.
For 26CV12 it should be : 128 - 64 - 6 = 58 L bits.
Anyway, with both options, my chips are completely inert, one of them returns all zeroes, the rest return all ones, when read.
Will let you know when I try the new chips.

[ole00]

Question, why the 86 for the GAL26

I tried a value of 58 (96 + 26 - 64) as described on the armory.com site for GAL26CV12, but that did not work on my non C GAL26V12. So value 86 was determined experimentally by checking the written PES - it was shifted few bytes off of the correct position. Later on I realised the GAL26CV12 uses different fusemap, therefore for non C version the PES bit address is different. Perhaps another test with value 58 might work better for you. Ensure you erase your GAL26CV12 before you try (if you haven't done so) as the ICs might be protected.

EDIT: I see you've already tried value 58, thanks for trying then.
EDIT2: armory.com mentions the Erase-All row is 57 for GAL26CV12, while Afterburner uses row 60 for this purpose - which might be incorrect. So, that's another quick test how to try to fully erase your GAL26CV12 (modify the galInfoList[] array and replace value 60 of 'eralseallrow' for GAL26CV12 to 57). Use parmater '-all' when erasing the GAL by the 'e' command to erase all GAL fuses including the PES signature.

[ceteras]

I've already changed the "erase all" row to 57, tried "e -all", no effect.

[ceteras]

I'm closing this, as 22V10 works now, thank you!