What's new

Fluffy

Champion
Joined
Dec 15, 2018
Messages
864
Reaction score
1,650
Location
Germany
After debugging another project for a while I finally got it to work - by replacing the ATF22v10C with a Lattice 22v10B. Same programmer, same jed file, etc.

The problem was that the ATF22v10 completely shut down, and produced logic levels at the output that had absolutely no relation to the inputs. I tracked it down to a high signal on pin 4. According to the data sheet this is a "power down" mode...
I never configured this in WinCUPL, and the TopALL software has no separate "power down" mode device for the 22v10. I did notice that the JED file has 5856 fuses, while the view in TopAll has only 5828 fuses. So I assume some important information at the end of the JED file gets cut off.
Unfortunately the developer for the TopALL software has fallen off the internet... Or is there a newer version than 8.37?
 
Interesting, thanks for the feedback.

@Mitsurugi-w had issues using ATF22V10s in place of GAL22V10s on the S16B multi, but he's not using the TOP3000.

My understanding is the programming algorithm is different between those two.
And the TOP3000 only supports GAL22V10.

P.S.: I think there's a V8.8 in existence
 
Yeah, the programming algorithm is different: http://www.bhabbott.net.nz/atfblast.html

Mine definitely lists ATF22V10C and Lattice 22V10B separately, and outside the power down feature it works fine. It's a bit frustrating, because they seem to be the only "new from factory" source, and you would expect a feature like this to default to "off".

I'm looking if I can cobble together an ATF blaster, but I'll have to find a computer that still has a parallel port, first. :)
 
Yep never got the ATF22v10 to work so constantly sourcing used lattice gal22v10c.
 
Mine definitely lists ATF22V10C and Lattice 22V10B separately
The TOP3000 software does show few information regarding the selected chip including Vcc and programming algorithm. I bet it uses the same one with no distinction between Atmel and Lattice. I can check that when I'll be back home.
 
My version says "P22v10" for the Lattice chip and "ATF22V10C" for the ATF chip. According to the description from the ATF blaster it shouldn't work at all without the different algorithm, and I get normal behaviour outside of pin 4.
 
My version says "P22v10" for the Lattice chip and "ATF22V10C" for the ATF chip. According to the description from the ATF blaster it shouldn't work at all without the different algorithm, and I get normal behaviour outside of pin 4.
I see. Then they goofed up the ATF algorithm.
Not surprising (already found a problem with 27C4002 burning and 74LS393 testing).
 
I think I found something interesting.

The ATF22V10 supports 3 modes:
- PAL Mode (5828 Fuses)
- GAL Mode (5892 Fuses)
- Power-down Mode (5893 Fuses)

I have no problem generating jed files for each mode BUT no programmer I own handles the last fuse (5893).
Since a fully erased chip contains only 1s, not being able to write that very last fuse implies it stays as a 1 hence Power-down Mode activated. I'm trying to find a way to write a 0 there.
 
My plan is to port the ATF blaster code to a teensy 2++ I had lying around...

So far I've got the usb gubbins done so Windows recognises it and automatically installs WinUSB. That was pain, as the example code relied on some non-standard GCC extensions not supported in the latest AVR Studio. I've got a simple Win32 application talking to it.

Next step is a simple test vector playback system to test usb communication and the circuit.

After that I hope to extract the programming algorithm(s) from the ATFblaster code and convert it to run on the microcontroller. Wish me luck!

By the way, the fuse bit was my reasoning as well. Though my thought is: ATF22v10 is advertised as a drop-in replacement for various GAL and PAL types, and as those will not contain data for the last fuse it should stay in "erased" (=1) state, which should default to "feature disabled".

The only way to tell will be to dump a GAL programmed with my other programmer once I've got the circuit working...
 
Last edited:
By the way, the fuse bit was my reasoning as well. Though my thought is: ATF22v10 is advertised as a drop-in replacement for various GAL and PAL types, and as those will not contain data for the last fuse it should stay in "erased" (=1) state, which should default to "feature disabled".


The only way to tell will be to dump a GAL programmed with my other programmer once I've got the circuit working...
The jed files I've generated tell me otherwise: fuse 5893 = 1 means power down mode active (you can quickly try yourself, chip type p22v10 for PAL mode, g22v10 for GAL mode, g22V10cp for power down mode).

That's probably where the problem comes from, stupid implementation in the chip and incomplete support by most programmers (even the Dataman 48 doesn't handle it properly...).
 
An other interesting finding: the jed files generated in PAL mode do seem to work well.

[EDIT]
Spoke too soon, no change... :(
 
Last edited by a moderator:
Finally found a solution!

As explained before the ATF22V10 has one additional configuration bit (@5893) for power down mode (0 = disabled, 1 = enabled).
By default when a GAL is erased all its bits are set to 1. The problem is by generating a standard g22v10 jed file, nothing specifies which state should have that extra bit so it's left to its default state = 1.

The solution I found is to manually edit the jed file. Two changes are needed.

First you have to modify one of the first lines specifying the number of bits, from 5892 to 5893:

1629985586239.png


1629985613057.png


Then at the end of the file you must append a new line, by calculating the position of the last bit in the file:

1629985700407.png


Here last line containing bits starts at L05856, last bit in the line is thus 5887. Simply insert a new line starting at L05888 containing five 0s (bits 5889 to 5893, since numbering starts at 0):

1629985853876.png


Of course checksum will then be wrong, I haven't investigated how to fix it for now but should be pretty simple.
Some programmers will refuse to load the file because of that, others will issue a warning, others simply don't care.
One last thing, some programmers algorithm won't let you write bit 5893 at all.
 
Back
Top