Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problem with ATF16V8CZ-15PU and a story #13

Open
lucadelpollo opened this issue Sep 27, 2021 · 14 comments
Open

Problem with ATF16V8CZ-15PU and a story #13

lucadelpollo opened this issue Sep 27, 2021 · 14 comments

Comments

@lucadelpollo
Copy link

Hi guys,

so I just built the Afterburner ( let' see if I can add a pic here ) , this is my version using Arduino Pro Micro and SW I lightly modified to make it work with Platform Io

AfterBurner

As you can see I went for the route of "an external power supply", no rocket science, plain simple 78S05 with some caps.

I had a bit of a nightmare story with the MT3608 module, I found out for me the simplest way was to lift up pin 4 and solder a small wire , but I also found the set ( 5 ) I bough on Amazon was defective, it was missing a connection between a resistor and the feedback loop making the regulation non-existent ( luckily it was stuck at 4.84V ), you can see a second wire in my pic ( that's the missing connection ).

Anyway so far been trying with 2 chips with the VPP set at precisely 10.0V , an ATF22V10C and an ATF16V8CZ

With the 16V8C I get the following thing ..

afterburner -v -t ATF16V8B i -d COM11

Afterburner v.0.3
opening serial: \.\COM11
read: 5 ''
opening serial: \.\COM11
read: 5 ''
opening serial: \.\COM11
sending 'p' command...
read: 62 'PES info: 3.3V Unknown GAL, try VPP=10..14 in 1V steps'
PES info: 3.3V Unknown GAL, try VPP=10..14 in 1V steps
result=0

( what is that read '62' is the ID code ?? )

If I try with the 22V10 instead things seems to go OK ( I yet have to try the chip itself ) however just to let you know this is what I see ..

afterburner -t ATF22V10C i -d COM11
PES info: Atmel ATF22V10C VPP=10.0 Timing: prog=10 erase=25

JEDEC file for ATF22V10C
QP24QF5892QV0F0G0X0*
L2156 11111111111111111111111111111111111111111111*
L2200 11110111111111111101111111111111111111111111*
L2904 11111111111111111111111111111111111111111111*
L2948 11110111111111111110111011111111111111111111*
L2992 11110111111111111101110111111111111111111111*
L3652 11111111111111111111111111111111111111111111*
L3696 11110111111111111101110111011111111111111111*
L3740 11110111111111111111111011101111111111111111*
L3784 11110111111111111110111111101111111111111111*
L4312 11111111111111111111111111111111111111111111*
L4356 11110111111111111101110111011101111111111111*
L4400 11110111111111111110111111111110111111111111*
L4444 11110111111111111111111111101110111111111111*
L4488 11110111111111111111111011111110111111111111*
L4884 11111111111111111111111111111111111111111111*
L4928 11111111101111111111111111111111111111111111*
L4972 11111111111111111111111111111101111111111111*
L5016 11111111111111111111111111101111111111111111*
L5808 00000000000000001100*
N UES 30 30 20 00 00 00 00 00*
L5828 0011000000110000001000000000000000000000000000000000000000000000*
N PES 33 43 30 31 56 32 32 46 31 FF*
C5EC5
*

And this is the original .JED file I used as output by WinCPUL .. as you can see despite "verify" and all is O.K. the file looks a bit different ( look at those lines of '000000' ) is that normal ?

CUPL(WM) 5.0a Serial# 60008009
Device g22v10 Library DLIB-h-40-1
Created Sun Sep 26 15:57:05 2021
Name VT100
Partno 00
Revision 01
Date 31/07/2021
Designer Engineer
Company XXXXXXXXXXXXXXX
Assembly None
Location Wales
*QP24
*QF5892
*G0
*F0
*L02144 00000000000011111111111111111111
*L02176 11111111111111111111111111110111
*L02208 11111111110111111111111111111111
*L02240 11110000000000000000000000000000
*L02880 00000000000000000000000011111111
*L02912 11111111111111111111111111111111
*L02944 11111111011111111111111011101111
*L02976 11111111111111111111011111111111
*L03008 11011101111111111111111111110000
*L03648 00001111111111111111111111111111
*L03680 11111111111111111111011111111111
*L03712 11011101110111111111111111111111
*L03744 01111111111111111110111011111111
*L03776 11111111111101111111111111101111
*L03808 11101111111111111111000000000000
*L04288 00000000000000000000000011111111
*L04320 11111111111111111111111111111111
*L04352 11111111011111111111110111011101
*L04384 11011111111111111111011111111111
*L04416 11101111111111101111111111111111
*L04448 01111111111111111111111011101111
*L04480 11111111111101111111111111111110
*L04512 11111110111111111111000000000000
*L04864 00000000000000000000111111111111
*L04896 11111111111111111111111111111111
*L04928 11111111101111111111111111111111
*L04960 11111111111111111111111111111111
*L04992 11111111110111111111111111111111
*L05024 11111111111111111110111111111111
*L05056 11110000000000000000000000000000
*L05824 11000011000000110000001000000000
*C5EC5
*�46E7

Thanks a lot for any help, btw I know very little about how to use GitHub ( I am used to SVN ).

Any help appreciated, cheers.
@ole00
Copy link
Owner

ole00 commented Sep 28, 2021 •
edited
Loading

Hi, thanks for the report. It looks like a neat build. To answer your questions:

  • the number after the "read:" is the total characters read from the serial line. For example "read: 5" means it read 5 bytes from the arduino device. It's really just a debugging info in case the serial connection is not working properly.

  • The JDEC format in both files seems to be correct even though it is not "styled" identically. Important part is the checksum C5EC5 at the end of the file, which matches on both of the bitstreams - that means the contents is most likely the same (16bit CRC is not a 100% guarantee the contents is the same though). You can also check bit by bit (see those 0 and 1's in the jdec files) and verify them manually if you want to be sure.

  • Related to why ATF22V10C works and ATF16V8CZ does not - I don't know. AFAIK nobody reported / investigated the C version of ATF16V8. I personally don't have the C version of the ATF16V8 (I only have the B version). If you look into the afterburner's arduino code the C version of ATF22V10 reverses the order of bits of the address (see sendAddress() function) compared to B version. It may be something similar for the C version of ATF16V8. Try ATF16V8 B version of the IC to verify your Afterburner device/build is correct (for functionality of 16V8 devices), then try to reverse the bit order of the address sent to the the C version of ATF16V8 (if you have time and would like to experiment) - in this case you may need to try different things, like reverse order of bits in setRow() function etc.

@lucadelpollo
Copy link
Author

Hi,

"because it was making me mad" .. I spent/spending quite some time checking the sources of the PC and Arduino stuff.

So the be clear the bits in the JDEC file, I see, are from LEFT to RIGHT , LSB TO MSB so 1000 0000 is actually 0x01 NOT 0x80 ..

Then if I understood correctly "upload()" reads the bits like that but then sends a command "in chunks of 32 bits like :

#f 2240 0F000000

THAT ONE in particular "was making me crazy" because looking at the matching line in the JDEC generated by WINCUPL that is :

*L02240 11110000000000000000000000000000

And I was AHA THAT SHOULD BE 0xF0000000 but no . .it is actually 0X0F000000 ...

Also I am noticing that "both upload and read jedec" SKIP all the 32 bits group that are all 0 ( and assume/set the fusemap all initialised to 0x00 ) so a line let's like like L0100 00000000000000000000000000000000 will NEVER be uploaded/etc. because "there's not even an '1' in it".

And now I understand also "why the formatting is all else" and you can't visually match it ..

It's because printJedec() does something similar, skips rows of 0 until it gets a '1' so in fact dumping the "first" 000000000000 so instead of starting at L02144 starts at L2156 ..

So "as a matter of because it bothers me so much" .. I am trying to modify that function in some way to get it printed
the same way that WinCUPL does :) ( probably by rounding up the address to the 32 block once a '1' is found or such ).

Anyway "it's a bit more clear what's going on" to me now :)

@lucadelpollo
Copy link
Author

Hi,
after spending 2 days modifying this and that "I got close to but no cigar" .. but I'll keep trying ...

HOWEVER, I can state that with a 16V8B the programmer works CORRECTLY and programs/verifies the .JED file ( generated via WinCUPL ) with no problems.

I'll try to see if I can investigate the mystery of the CZ, the reason of "why CZ" is because that was the one that my usual supplier has, I got the 16V8B instead from DigiKey.

I must find ( and study ) some better documentation about PLDs, "just to let you know" how I spent TOO much time I did modify the first part of printJEDEC() as that ..

unsigned short i, j, k, n, k1, shesha;
unsigned char unused, start;

Serial.print(F("JEDEC file for "));
Serial.println(galinfo[gal].name);
Serial.print(F("*QP")); Serial.println(galinfo[gal].pins, DEC);
Serial.print(F("*QF")); Serial.println(galinfo[gal].fuses, DEC);
//Serial.println(F("*QV0*F0*G0*X0*"));
Serial.println(F("*G0"));
Serial.println(F("*F0"));

//return;

for( i = k = 0; i < galinfo[gal].bits; i++) {
 
    unused = 1;
    n = 0;
      for(j= 0; j < 32; j++, k++) {

        if (unused && getFuseBit(k)) 
          {
            k1 = k & 0xffe0;
            if (k1 < k)
            {
					      shesha = k - k1;
					      j -= shesha;
            }
            unused = 0;
            n = 0;

            k = k1;

            line[n++] = 'L';
            n = addFormatedNumberDec4(k, n);
            line[n++] = ' ';

				      k--;
				      j--;

          }
			    else
			      {
				      if (!unused)
				      {
				        if (getFuseBit(k)) {
						    unused = 0;
						    line[n++] = '1';
				  	    }
					    else {
						    line[n++] = '0';
					      }
				      }
          }
      }

    line[n++] = '*';
    line[n++] = 0;
    if (!unused) {
      Serial.println(line);
    }

} // end of bits loop

return;

However .. "something goes odd after" .. when it start the other loop

if( k < galinfo[gal].uesfuse) {

etc. etc. ..

But anyway I think for the moment I'll leave it as it is as I don't know ( yet ) much exactly how a PLD works I just looked at the code thinking "I can modify it a bit" .. which kinda works but doesn't, it does stop printing fuses "much too early" and I really don't understand what bits/columns/etc. means "any computation I try gives me nonsense results" ..

i.e. for example I don't get what are "bits" compared to "total number of fuses" and "rows" nothing seems to be even remotely a multiple of 8 and whateve numbers I multiply nothing seems to make sense .. certainly those PLDs seems to be quite odd devices :)

My next step will be to build the HW the PLD is supposed to go in and make it work.

But yeah, 16V8B, no problem, 16V8CZ still problem.

@ole00
Copy link
Owner

ole00 commented Oct 25, 2021

I'm glad the 16V8B works for you. I got the ATF16V8C in the meantime, tried few tricks I mentioned earlier but I had no luck making it to work with Afterburner. It would be nice to have a support for the C version, but considering the B version and some 16V8 GALS from other manufacturers work OK I don't see it as critical. I'll update the readme pinpointing the C version ATF16V8 has different programming protocol and is not currently supported.

If somebody has an ATF16V8C programmer (like TL866ii which seems to support it) and would like to investigate a bit (presumably with a logic analyser, ensure the VPP is not connected directly to your LA as it may fry it with a higher-than-max voltage) that would be cool. Perhaps just starting the programming sequence with no IC inserted or some other 16V8 GAL inserted would suffice to detect the protocol differences.

Related to your new priting/formatting code: It's good it does not work for you, you can learn few new bits (pun intended :).
I suggest to copy the whole function (normally run on Arduino) into a standalone C programm (you can even hack the 'afterburner.c' and put your function in there. Then call the function right at the top of the main() function and debug what goes wrong (ensure you have the fuse bit array in the C code as well possibly pre-filled with some data). You can then use 'gdb' to step through the code and investigate the printing behaviour.

.e. for example I don't get what are "bits" compared to "total number of fuses" and "rows" ...

Fuse in this case is a single bit. This is how these devices were traditionally constructed - like OTP (one time programmable) where each bit/fuse had to be blown in order to change the bit (in the memory array) from 1 to 0. Once the fuse was blown - that was it, you could not flip the bit back to 1 (that's why it probably needed the higher VPP in order to blow it) . The modern devices are re-programmable (have flash memory inside) but the naming convention stayed the same, so they refer to an individual bit in an array as a fuse.

nothing seems to be even remotely a multiple of 8 and whateve numbers...

Think about the whole fuse array as a 1 dimensional array - just as a long string of 1s and 0s. Each bit has it's own address/position (in that 1D array) and you can then divide/break-up the long string to smaller parts (the rows) of any size you want. It does not have to be 8 bit multiple. Hope it helps.

@ole00
Copy link
Owner

ole00 commented Mar 28, 2023

Just an update: ATF16V8CZ is now supported in the latest code.

@lond131421
Copy link

ATF16V8CZ still cannot support it, I found that the program written in does not match the source program.

@lond131421
Copy link

When ATF16V8CZ uses afterburner to read the generated Jed file and then brushes it back, there will be a problem of different programs before and after. If only the ATF16V8CZ program is flashed, it is normal; I used a professional programmer to read the source program Jed file of ATF16V8CZ, and it is normal to write it in afterburner.

@lond131421
Copy link

I am Chinese, please understand if my English is not good.

@ole00
Copy link
Owner

ole00 commented Jun 3, 2024

@lond131421 : can you give an example of the JED file, that does not work for you?

@lond131421
Copy link

lond131421 commented Jun 3, 2024 via email

@lond131421
Copy link

lond131421 commented Jun 4, 2024 via email

@ole00
Copy link
Owner

ole00 commented Jun 4, 2024

Please refer to the data read before erasing and the data written to test.jed after erasing, which is completely incorrect.&nbsp

  1. Please list the contents of the test.jed here, so I can check it with my Afterburner.

the Atmel ATF16V8CZ model did not appear.

  1. Which parameters did you use when running afterburner to show the model?

Finally, I erased the chip and rewrote it to ATFB11. jed (the original file of the chip), and after reading it, it returned to normal

  1. How did you do erasing writing and reading ? Did you use Afterburner to do that?

  2. Do you have the latest version of afterburner installed (both on Arduino and on PC)? If not, which version do you use?

  3. Which board/PCB version of Afterburner do you have?

Please answer all questions 1 to 5, so that I can help you to resolve the issue.

@lond131421
Copy link

lond131421 commented Jun 4, 2024 via email

@ole00
Copy link
Owner

ole00 commented Jun 4, 2024

OK. no problem. I'm glad it works for you now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ole00 @lond131421 @lucadelpollo