Current inexpensive programmer for 22V10's 16V8's?

[HHaase]

Can anyone recommend from the current crop of programmers an inexpensive option for handling current generation ATMEL 22V10's and 16V8's? 
Most of the info I'm digging up via google is for older, or far too broad (expensive) options.   I don't need to program PIC's, AVR's or much of anything else.
Already have a GQ-4x for handling EPROMS and the few other things I currently need to program.

But what I do need is something that is USB / WIN10 compatible,  not overly expensive,  that can handle Atmel's 5v SPLD's and CPLD's

Any suggestions?

-Hans

[nctnico]

I bought the TL866 minipro for programming GALs but I have not tried it yet.
Dave did a review a long time ago: https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/

[HHaase]

Looks like it lists the ATF16V8,   which means it 'can' program GAL's,   but I don't see anything else listed from Atmel.

Perhaps I'll download the current software set at see if anything else has been added.

-Hans

[Bruce Abbott]

The TL866 cannot program ATMEL 22V10's. That's why I built my own programmer for them.

I now have a Stager VS4800 which does program the ATMEL 22V10, and also seems to be more reliable. VS4000 is the 40 pin version, which sells for ~$70 on eBay.

The only thing I don't like about the VS4800 is that chips must be placed upside down in the ZIF socket, and the instructions for where to insert them are ambiguous. I use the unit inverted (so pin 1 is at the top) and labeled it to remind me to put the chip in the 'bottom' end of the socket (closest to the top of the unit). Occasionally it reports a bad connection, which can be fixed by moving the chip in the socket to clean any oxidized pins.
   
   
 

[HHaase]

Bruce,  good to know,  I'll have to dig further into your post there to check out your options.

Looks like there may be another option, kinda, in the cheapie programmer world.
The G540 lists a lot of 22V10, 20V8, 16V8 part numbers, including the ATMEL pieces I'm looking at.
Should be plenty for me for now since I'm just getting started.  Though I am always a bit hesitant when I see super-cheap stuff in this market.
They tend to over-promise and under-deliver.   Doesn't handle their ATF15XXX series,  but Atmel does offer a dev kit that can handle those if I need the extra size of the PLC44's.

[westfw]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

[netdudeuk]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

Have a look on the main TL866 thread. There's mention of GAL22V10s on there. Mine used to do them ok but a software update broke things. I bought a G540 to do subsequent ones.

[Bruce Abbott]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

It does other 22V10's but Atmels are different. I have done a bit of research on this. Their programming algorithms are super secret and AFAIK have never been released to the general public.  A Russian guy modified Galblast to do Atmels, so I had a go at hacking into the executable to see what he did. However the file is packed in an old format that modern disassemblers won't touch, and I have better things to do with my time.  Since then I found a post (in Russian!) that explained the changes required, but I have a proper programmer now so...

For anyone who's interested, here's a translation of the post:-

Special thanks to Vladimir Misyachnomu ("Misyachniy Vladimir") for their valuable advice.
Galblast 1.6 after rework is now sews ATF22V10B.
By adding a delay after installation SDIN, I lost ATF22V10B :-)

It turned out as an interesting detail: this delay should be proportional to the pulse time
programming -STB, and also depends on the programming voltage. So I have tested the
following combinations for which the chip was successfully written:

12V: Delay programming pulse (pulse)

7.5V: Delay programming pulse (pulse)

Further delay is only needed when writing to chip reading also works successfully
and without (pulse = 0 ;-))

Changes in Galblast 1.6:
It was:
static void SendBit (int bit)
{
SetSDIN (bit);
SetSCLK (1);
SetSCLK (0);
}
It was:
static void SendBit (int bit)
{
SetSDIN (bit);
if ((gal == ATF22V10) && writeorerase)
Delay ((pulse = 1)? 3: 1 pulse * 2+);
SetSCLK (1);
SetSCLK (0);
}
Now it works, and on simplified scheme. Power (7.5..12) v served at once (simultaneously)
on EDIT and 7805, c last 5v at Vcc PLD.

I corrected the program. It was and remains. I just handled the firmware and change the
order of bits in the address for firmware Galblast with ATF. I'll try a program from AGK,
recheck and publish files by stitching ATF Galblast.

 

[netdudeuk]

The TL866 cannot program ATMEL 22V10's.

Can't?  Or just doesn't have it in their vendor/chip table of supported devices?  How different IS one vendors' 22v10 from another, WRT programming, anyway?

It does other 22V10's but Atmels are different.

Beware.  As I mentioned above, there are issues with some 22V10s.  Start at post #675.

https://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/675/

Mine have the Lattice logo on them but they came from China so who knows what they are.

[Bruce Abbott]

The TL866 cannot program ATMEL 22V10's.

Beware.  As I mentioned above, there are issues with some 22V10s.  Start at post #675.

I didn't read the whole thread, but right off the bat I see that he had 'Encrypt ch' enabled. This will cause verify to fail.

Mine have the Lattice logo on them but they came from China so who knows what they are.

That could be a problem, but even with genuine chips it can be tricky. I have several GALs which were pulled from surplus equipment that I know are fine, but the TL866 thinks they need a different programming voltage than what the datasheet says. I also have a bunch of remarked GALs from China, and they all identify correctly (apart from the voltage issue) and work perfectly.

There are many variations between GALs of the same type (even from the same manufacturer) that may or may not be an issue. Atmel GALs must be conditioned before first use by writing a blank pattern to them several times, or they will fail. The ATF22V10B has 5828 fuses, but the ATF22V10B(UES) has 5892 fuses.


   

[HHaase]

Glad I asked the way I did, specifying the ATMEL parts, and really appreciate all the info coming in.    For all the things I can find on the 'net on technical stuff,  everything I see regarding SPLD's and CPLD's is very dated info,  much of it assuming you understand big chunks of prior knowledge.   

But man can it be a struggle to get started.   

[Bruce Abbott]

The ATFblast program seems to work, but I wasn't happy with using a closed-source hack. So a few days ago I decided to get serious about studying GAL programming algorithms, hoping to figure out how to modify GALblast to work with the ATF16V8B and ATF22V10B. Turns out that the problem with ATF chips is not that they have different programming algorithms, but two issues inside GALBlast itself:-

1. GALblast  examines bits in the PES (programmers electronic signature) to determine the vendor, chip type, programming voltage and pulse period. But ATF chips don't have this information in the PES, they just a have a text string representing the part number. So GALblast tries to interpret the bits in the text and screws up, setting programming parameters that don't work. 

The solution to this problem was simple; just tell GALblast to ignore the PES when an ATF chip is selected, and hard code in the correct parameters.

2. Now when GALblast tries to program an ATF chip it mostly works, but some of the bits are corrupted. In particular, the first  '1' bit that follows a '0' bit tends to get written as '0'. The author of ATFblast says the fix was to add a delay of ~20ms before clocking each bit into the fuse row buffer. But with 132 fuse bits per row and 44 rows the delays add up to a very long programming time, much longer than other programmers need. Something isn't right about this 'fix'.

Why is such a long delay time necessary for each bit? Theoretically the chip shouldn't start writing until all the bits in the row have been received and STROBE is pulsed. But what if it did? GALblast sets the P/V- (program / not verify) pin high for the whole time the chip is being programmed. Perhaps ATF chips need to be in verify mode until the row buffer is filled? So I changed the code to set P/V- high just before pulsing STROBE, and lowering it immediately afterwards. Success! I can now program an ATF22V10B perfectly in a few seconds.
     
I still have to test my modified GALblast code with the ATF16V8B and other standard GALs. Once this is done and I have proved that they can all be programmed reliably, I will release the source code.

Next step is to get it working with the ATF22V10C (which has a slightly different programming algorithm). Then I will try making a programmer that works via USB/serial, for use with modern PC's that don't have a parallel port. I am thinking a $3 Arduino Pro Nano clone might do it.

[Bruce Abbott]

Although the ATF22V10B was programming correctly, a couple of bits in the UES (User electronic signature) seemed to be stuck high on read. This also occured with ATFblast. UES contents have no affect on logical operation so I could have ignored it, but I wanted to know why it was happening. So I built a simple parallel port logic analyzer (Elmuesoft 17 Channel Logic Analyzer) to monitor my VS4800 while it was programming GALs. This revealed some interesting things:-

1. The 'stuck' bits do exist, but are not part of the UES. The UES fuse line has a total og 132 bits. On a normal GAL22V10 the first 64 bits are the UES, and the rest are blank. In the ATF22V10 it's the other way around -  the last 64 bits are the UES.     

2. On the ATF22V10C, data is not transferred on clock rising edges as suggested elsewhere, but on falling edges just like other GALs. However only 5 clocks are used to transfer the 6 address bits at the end of each row, the last bit being input directly without being clocked in.  If you try to clock in 6 bits then it 'works' with rising edges because the last rising edge doesn't do anything, but data may be corrupted if falling edges occur at the wrong time. 

3. The VS4800 always writes a blank user signature even when a 'UES' chip is selected. It also disables the power-down feature when programming the ATF22V10CQZ, even when enabled in the JEDEC file (probably a good thing since power-down, which is enabled by default, makes pin 4 unavailable for logic input).
     
4. Delays of several milliseconds between most operations are not necessary. Programming any GAL should only take a few seconds at most.

5. My theory that (on the 22V10) P/V- should be set high only when pulsing /STB is confirmed.
     
With my current code I have successfully programmed an ATF16V8B, ATF22V10B and ATF22V10CQZ, and read various GAL16V8s and 22V210s. I have yet to confirm that standard GALs can still be programmed (maybe I have somehow broken that code) but since the original GALBlast already does them I am not overly concerned. I have also simplified the hardware a bit by removing the pull-down resistors and changing the ATF's programming voltage from 11V to 12V.

The attached zip file includes preliminary source code and executable for my version of 'ATFBlast'.  As well as ATF chips it should also do the GAL16V8, GAL20V8, and GAL22V10. I removed some less popular GALs that were cluttering up the menu.
 
Next I want to port my code to an MCU so it can be used on modern PCs that don't have a parallel port. Thinking of modifying this project which uses an Atmega644 (but probably only needs an Atmega328).
 

[Joe1000]

Hi Bruce

I did a test today using an atmel atf16v8 with atf blaster minimum hardware and your atfblast sw modified.. it works
but using the verification tab , the message was.. failed

I am sending two attachments:
The Hex7Seg.jed is a test file downloaded from internet.. and the result.jed is the jedec saved after writing it on ATF16V8

Do you have some idea about how to fix it?
(For example:  L2048 11111110* seems too short..is it normal?)

Thank you very much!

[Bruce Abbott]

Your main fuse plot (fuse numbers 0-2047, 2048-2055,  2120-2127, 2192 and 2193) and UES (2056-2119) appear to have been programmed correctly. The line that looks 'too short' is actually OK (trailing '0's do not have to be shown because that is the default value). 

The PES (programmer electronic signature) is blank (all FF), whereas it should be something like  31 42 38 56 36 31 46 31 ('1F16V8B1' in reverse). This suggests that it has been erased, or that the programmer is not able to read it. However the PES is only provided to tell the programmer what chip it is programming. It doesn't affect device operation and is not normally programmed or verified.   

Most of the Config fuses between 2125 and 2191 are reading '0' when they should be '1'. This is probably the cause of the verify error. I am not sure what these fuses do (product term disable?) so I can't say whether they are important or not.

According to the documentation provided with some programmers, Atmel SPLDs need to be programmed and erased at least twice to 'condition' them, and may fail to verify until this is done. If your chip is new then programming and erasing it several times might fix the  problem. If not then just test it for functionality and if it works don't worry about the verify error.

[Joe1000]

I will test the  'condition' programming and post the results soon

 

[Bruce Abbott]

Attached is version 0.3 of ATFBLAST. This fixes some minor bugs and improves detection of different GALs. With this version I have successfully programed the following chips:-

National GAL16V8
Lattice GAL16V8A, GAL16V8B, GAL16V8D
Lattice GAL22V10B
Atmel ATF16V8BQL, ATF22V10B, ATF22V10CQZ

More chips may join this list after I get them from eBay. 

I have also made some progress on the AVR-based GAL programmer (code written, need to breadboard the circuit and test/debug).
   

[hlavac]

Any progress? I would like to build one

[SiliconWizard]

I bought the TL866 minipro for programming GALs but I have not tried it yet.

I have one and used it successfully to program GAL, EEPROM and FLASH chips. Very handy and cost-effective.

The only GAL chips that I programmed with it were Lattice GAL16V8D and that worked very well. Apparently, it won't work with ATMEL GALs for some reason?

[Bruce Abbott]

Any progress? I would like to build one

ATFblast is (hopefully) complete. I just received some GAL20V8's to test, so I will soon find out if it works with them.

I have built prototype hardware for the AVR GAL programmer, and am now debugging the firmware. I refactored the code and expanded it to support ATF16V8 and other GALs, and also added back in some features from GALblast that the author of Burnit had removed. This has taken a bit longer than I expected.

The ATmega328 only has 2K RAM so all static data is placed in ROM, and the (up to 5896 bit) fusemap is stored as individual bits in an array of 737 Bytes (unlike GALblast which uses 1 byte per fuse bit. Oh the joys of PC programming, where RAM is plentiful so you can afford to waste it!). This would be no problem in assembler, but C doesn't support bit arrays directly and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word(). If I didn't the compiler generated no warnings, but read from the wrong address!

         

[lazarusr]

I have built prototype hardware for the AVR GAL programmer, and am now debugging the firmware. I refactored the code and expanded it to support ATF16V8 and other GALs, and also added back in some features from GALblast that the author of Burnit had removed. This has taken a bit longer than I expected.

The ATmega328 only has 2K RAM so all static data is placed in ROM, and the (up to 5896 bit) fusemap is stored as individual bits in an array of 737 Bytes (unlike GALblast which uses 1 byte per fuse bit. Oh the joys of PC programming, where RAM is plentiful so you can afford to waste it!). This would be no problem in assembler, but C doesn't support bit arrays directly and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word(). If I didn't the compiler generated no warnings, but read from the wrong address!

Hi Bruce, Any further updates on this project? I think there would be a fair bit of interest in this.

[westfw]

C doesn't support bit arrays directly

It should be pretty easy to write "wrapper" functions  to access a bit array.C++ has http://www.cplusplus.com/reference/bitset/bitset/ (I have no idea if it works on AVR.  It's and existence proof that it COULD be implemented.)

and AVR GCC has some issues with arrays in ROM. It took me 3 days to figure out why the config array wasn't working. Turns out that just declaring the array as PROGMEM wasn't enough, I also had to access the array elements with pgm_read_word().

Ah; you should have read one of the tutorials...Actually, current avr-gcc has a "__flash" named address space ( https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html ) that would behave the way you'd want it to.

[Bruce Abbott]

C doesn't support bit arrays directly

It should be pretty easy to write "wrapper" functions  to access a bit array.

That's what I did.

Actually, current avr-gcc has a "__flash" named address space ( https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html ) that would behave the way you'd want it to.

I am now compiling with AVR GCC 4.9.2, which uses this syntax. I did have a few problems getting it to work with Atmel Studio 4 (had to replace avr-size.exe with the earlier version. The simulator crashes, but I am now familiar enough with AVR architecture that I don't need it).

Hi Bruce, Any further updates on this project? I think there would be a fair bit of interest in this.

I had to put it on hold while I was working for a company developing a new product. That project is (finally) done now, so I have some free time again!

I have made some progress. The programmer now automatically detects which GAL is plugged in, and reading is working fine. Next step is to try writing. Coding is done but probably full of bugs, so I need to verify correct operation before using live chips. For this test I have set up another PC to act as a dedicated logic analyzer.   

I am also attempting to port the code for my ATFblast (parallel port) programmer to 32 bit Windows, compiled with Borland C++ Builder 6. Got the code to compile without errors, but it crashes when run. Time to experience the 'joy' of debugging in Windows XP!     

[marinovsoft]

Hello, all!
I modified the galblast program for win32. It works on Windows XP/7/8/10, x86 and x64 Windows version supported. You can download from http://marinovsoft.narod.ru/radio/galblast_w32.7z (source code included). The program uses the inpout32 driver from http://www.highrez.co.uk/downloads/inpout32/

[jpham]

Does the Stager vS4800 support that 40 pins atf2500?
if not, what other programmer support that 40 pins atf2500?