PART 1
Hi all,
After having spent hours & hours of head scratching and web searching I finally got a toolchain working for programming ATF1504s.
Several people commented that it would be a good idea to document my work. So here goes...

Toolchains
These are my current toolchains for SPLD and CPLD development. I'll say it again, I'm a NEWBIE to the world of GALs / SPLDs /CPLDs. I started reading about them (on this forum, of course) less than a year ago, when I started *really* designing my 6502 WBC (c) Garth Wilson. That is to say once I realized that I could greatly reduce address decoding delays by "simply" replacing my 74xx138s with an SPLD.

All that I document here is the result of my long uphill struggle to get a) my brain around the new ideas; b) the tools to work...
So, what I use to effectively design for and "burn" :

ATF16V8/ATF22V10 : WinCUPL -> (.jed) Arduino AfterBurner
ATF150x : WinCUPL -> (.jed) ATMISP -> (.svf) OpenOCD + USB Blaster
(I'm also evaluating "Digital", which is a GREAT xPLD learning tool, also the generation of either WinCUPL input files or .jed directly)

So, let's get started. Turning an idea into a working design and .jed file.

WinCUPL (version 5.30.4 Atmel) running under/inside Wine (8.0.2)
Spoiler alert : I can't/won't give any real development advice here : perhaps someone on the forum could help-out...
But I *have* braved the dragons to especially understand how the simulator works, 'cos it's very useful for seeing if the CPL code actually works as expected!
Some things I've found out by accident and error, however :

• I work exclusively on Linux, and WinCUPL wants DOS/Win file endings, so before opening WinCUPL I run a short script on my .CPL file to ensure that I haven't left any non-DOS line endings (as I often forget and open the files with a linux editor instead of notepad)

Here is the script :

• as one should, for any sort of development (but we all get carried away, don't we), build and test little functional modules first and assemble them later - it avoids annoying the error dragons inside WinCUPL...

• keep archive copies of WIP, or better-still a revision mgmt. system, so you can roll back to the last version that worked just before that last bell/whistle that broke everything...

WinCUPL, if the wind is coming from the right direction and the dragons are sleeping, will generate a .jed file (and a useful .doc file that has a lovely drawing of the chip and it's pinouts). For the ATF16V8 or ATF22V10 chips this .jed file is all we need to program using a standard GAL programmer. The Afterburner that I mention above is an Arduino shield and is a great little project to build https://github.com/ole00/afterburner.

_________________
Glenn-in-France

PART2
So now we've managed to simulate our device functions and create a JEDEC file (.jed). As I mentioned above the .jed file is all we need to program simple GAL devices with a standard programmer. For the ATF150x devices, because they are more complex, we need other tools.

OPenOCD is a free and open-source project that is able to program and test many devices including very complex CPLDs. I decided to give it a try. The "standard" input file for OpenOCD is, however, a SVF (Serial Vector Format) file. More on OpenOCD later. First we need to convert our .jed....

ATMISP (version 7.3 Microchip) running under/inside Wine (8.0.2)
A quick step-by-step process to generate an .svf file from your .jed file created above :
( note : this process is also very useful for generating .svf files for ERASING a device and performing BLANK CHECK )
Start ATMISP
Click on "Options", then "JTAG Port check override" (this is supposed to stop ATMISP from checking if their programmer is present)

Click on "Edit", then "Add New Device"
(After which device ?) default to 0 : OK
Select the correct device from the drop-down text box (e.g. "ATF1504AS")
"JTAG Instruction" : select "Program/Verify"
(or "Erase" : to generate the correct Erase.svf [no JEDEC file needs to be defined])
(or "Blank Check" : to generate the correct BlankCheck.svf [no JEDEC file needs to be defined])
"JEDEC File" : click on "Browse" to select your .jed source file (e.g. <sourcefile>.jed )
Now, on the RH pane, activate the "Write SVF File" tick box, and supply the destination File Name in the text box (e.g. <sourcefile>.svf )

Click on the RUN button. You should see the message "JTAG instructions finished successfully" in the message pane.
Look in the source directory, you should find your .svf file(s) !

Now we're ready to BURN !

_________________
Glenn-in-France

You may want to see if your Linux has the commands: dos2unix and unix2dos built-in... they're quite handy for stuff like this.

Thanks for the rest of this.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

PART 3
Before going any further, we now need to talk nuts'n'bolts : we need to connect to our device-to-be-programmed...

There are many development CPLD boards out there, many of which are compatible with the Atmel/Microchip devices.

I already have far too many development boards for far too many different architectures, so I just bought a simple 44-pin breakout from the usual chinese supplier. It has to be wired with power supply and the JTAG signals, but it's not too busy for a breadboard ;

The JTAG signals from/to the USB Blaster are better seen on this schematic :

The 10-pin connector is the connection to the USB Blaster.
When wiring your breadboard (or designing your own breakout/dev board), DO :

• wire ALL of the Vcc and GND pins of the device;

• add some decoupling capacitors and perhaps a larger filter capacitor;

Unprotecting
If, like me, you buy your first 'victims' from the same chinese supplier 'cos they're very cheap - you'll invariably find that they refuse to be programmed or even identified. Don't bin them just yet. They are most probably read/write protected (or have the JEDEC pins reprogrammed for 'user' functions). They can be unprotected simply by applying a 'programming' voltage on one special pin. The pin is refernced "Vpp" on the above schematic. For the ATF150n series, the programming voltage is 12v. Be warned, if you apply 12v to ANY OTHER PIN of your device, you'll most probably let the smoke out of the box. Keep the 12v Vpp applied and you should find that the device will be properly identified. Sometimes there's an extra surprise : the device's ID doesn't match the printing on the chip!

A simple way of providing a suitable 12v on your spaghetti-board is to use an MT3608 step-up module, like this :

The input is your 5v (Vcc), you adjust the output to be 12v, and you can hot plug/unplug the 12v pin easily on the breadboard.

If your design leaves the JEDEC special pins unattributed, you should only need to unlock the device once.

IMPORTANT NOTES :

• ALWAYS use a series resistor - any value between 1k and 10k will work;

• ALWAYS respect the following sequence for applying the 12v :
  Startup : apply 5v power; apply 12v Vpp; do any programming.
  Shutdown : remove 12v Vpp; remove 5v power.

Now we have the hardware ready, let's get started with OpenOCD :

_________________
Glenn-in-France

PART4
OpenOCD (native Linux, version 0.12.0)

I did have troubles with the "preferred" version in the Mint/Ubuntu repositories and also the executable images on the openocd website https://openocd.org/ . Most probably because I have just soooo many dev tools on my dev PC...

So anyway I downloaded the full archive of the latest stable version and compiled and built it using the provided install tools.

I also fell into the usual "clone trap" : the USB Blaster I was given is supposed to be a V2 but it isn't. So I'll try to highlight the two processes for the two types of USB blaster ( V1 : ftdi interface or V2 : native USB ).

If installing from scratch, you'll need to ensure a few things for the USB communications to work (either version):

• ensure that you belong to the 'plugdev' group [ sudo usermod -a -G plugdev <username> ] Type just 'groups' to see what groups you belong to.

• be sure that the udev rules file lists the correct access permissions for the USB Blaster ( /etc/udev/rules.d/51-usbblaster.rules )
  it should look like :

(and no, the 666 isn't some mystical incantation - just R+W permissions !)

• locate where your openocd system is installed (generally /usr/share/... or /usr/local/share/...) 'cos you'll need the paths to some of the files.

Blaster V1 process :
... it *should* work out of the box ... Try typing (cut/paste ) this :

[ Note the "expected-id" parameter. If things don't seem to work correctly, check that the id really *does* match the ID of your chip ]

You should see a transcript like :


If you see this, especially the "tap/device found" part, then you're well underway ! Now's the time to check that the device ID is correct.

What all the above gibberish means :

any "-f" followed by <something> just means run the script contained in the file <something>.
In this case "altera-usb-blaster.cfg" is the configuration script for our ftdi-based USB Blaster.

any "-c" declarations are simply individual openocd commands :

-c "adapter speed" : set the communication speed (in kHz) of the session

(note that some adapters dont support variable speed : openocd will report a message but will function with the correct default speed - as above)

-c "jtag newtap ATF1504AS tap -irlen 3 -expected-id 0x0150403f" : add a new TAP (Test Access Port) to the JTAG chain.

Here we give the TAP a name (ATF1504AS); the type of device (tap, in this case, is used to declare CPLDs that have only 1 access port); -irlen is the Instruction Register Size (in bits) of the device; -expected-id is the JEDEC ID Code of the device.

-c "init" : initialize the device

-c "sleep 200" : I'll let you work-out what that does

-c shutown : do anything special for shutting-down the device (probably not required for our setup)

NOTE : all of these, and many more, commands are explained in the user guide (locally or online at https://openocd.org/doc-release/pdf/openocd.pdf )
NOTE : if your device refuses to identify itself, it may be that it is protected : see "Unprotecting" above.


Here is a sample programming session :
1) Erasing the device (using the Erase.svf file created in ATMISP, above) : (note that your path to openocd may be different to mine)

From this point onwards, you shouldn' need the Vpp voltage anymore. Remember to follow the shutdown sequence, remove the 12v and away you go!

2) Programming the device (here I'm using the code for Daryl "8-bit" 's 6502<->SPI interface) :


Blaster V2 process :
I haven't dug any deeper to find-out if there is an alternative, but using this version of the USB Blaster requires at least one file from the Quartus Lite package. As it turns-out I had already tried installing Quartus (it actually installs native Linux) to see if it would program the ATF150x chips (spoiler : it doesn't). There is a special openocd configuration file ( <path to openocd>/scripts/interface/altera-usb-blaster2.cfg ) that needs to be modified before trying to use the system. You'll need to be familiar with a text editor that can be run with "sudo" privileges (e.g. nano), to modify the file so it looks like :

( The higher privileges are required because the file resides in a directory where you normally only have read access. )
It is very possible that the blaster_6810.hex file is all that is required, and that it can be "procured" without treading on any copyright toes, but as I don't currently need this setup I'm not going to investigate further.

Once the config file is correctly modified, the rest is exactly the same, except you replace .../interface/altera-usb-blaster.cfg with .../interface/altera-usb-blaster2.cfg. You can follow the instructions for Blaster V1, above.

_________________
Glenn-in-France

Excellent, excellent write up!

I particularly interested in your way of erasing locked CPLD with .svf file. I'm a long time user of Quartus and EPM7xxxS CPLD. Quartus is much superior to WinCUPL and USB Blaster clone is much cheaper than Atmel programmer, but EPM7xxxS is no longer in production and the used parts are mostly locked. I've limited success unlocking with .pof programming file with 12V applied to /OE pin; your approach with .svf file is very interesting. I'll definitely give it a try!
Bill

I'm stuck with ATMISP not starting, it says FTD2xx.dll missing. There is no such thing for Windows 11 on ARM, I'm running Windows in Parallels on a MacBook Air M3. Anyone here that has ATMIPS V7.3 running on Windows 11 on ARM?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks BDD. And -at last- the penny has dropped that the tool is called unix to dos, not linux. So, yes, I already had it from the beginning. But the speed thing isn't really important. Besides, I'm quite nostalgic of the time on my HP1000 when I had time to go make a cup of tea when I compiled a Pascal/1000 program

_________________
Glenn-in-France

@cbscope

Did you get past that hurdle? I'm assuming that it's looking for the USB driver, but I'm not sure where you should pick it up from - unless it's the "standard" FTD232 driver? I have so many things running under wine on my system I don't really know where any of the DLLs came from.

_________________
Glenn-in-France

No I had no success. I also tried to manually install the FTDI drivers for Windows on ARM. Now the JTAG programmer ATDH1150USB is recognized and the drivers are loaded, but ATMISP still exits with the message FTD2xx.dll missing. I have contacted microchip support and they will look into the issue. It is really the last missing piece in order to be able to migrate everything to my M3 notebook. As a workaround I still have a MacBook Pro with an Intel with bootcamp. I even managed to get W10 running in a emulated i86 VM in UTM on my M3 but it is extremely slow. I‘m also still looking into a command line solution to create svf files, unfortunately the chn file does not allow to save svf as output, so using atmisp as commandline does not work. I let you know when I have an answer from microchip.

An alternative to ATMISP for converting Atmel .jed files to .svf is an open source tool called fuseconv.

This is part of Project Bureau, which is reverse engineering the Atmel CPLDs:
https://whitequark.github.io/prjbureau/ ... econv.html

The tool itself can be found in the Project Bureau github repository:
https://github.com/whitequark/prjbureau

It's written in python, so it cross platform.

I've used this successfully myself on an ATF1508AS:
https://stardot.org.uk/forums/viewtopic ... 55#p417055
https://stardot.org.uk/forums/viewtopic ... 96#p415696

No Windows system is required!

Dave

Just making a note for myself that a lot of plasmo's adventures with EPM7xxxS devices are posted here: ATF1504AS: Questions about this CPLD

And also that the LabTool-48UXP lists all the EPM7xxx devices as supported. Including the non-jtag non-S versions. But I have no idea where to buy the LabTool-48UXP, where to buy the adapters for the MAX7000 devices or if the LabTool-48UXP can supply the 12V needed put locked devices back in programming mode.

@cbscpe, and just for completeness: on a different thread,
akohlbecker said :

_________________
Glenn-in-France

Microchip stated that I should use the standard FTDI drivers and manually install them as it is required for Windows 11 on ARM and described in the document from FTDI. After that the JTAG programmer is recognized as USB device and the drivers are loaded, however ATMISP still refuses to start as it does not find the ftd2xx.dll. Alan from Microchip asked me to make some tests and create some screenshot. I also told him, that the FTDI standard drivers for Windows 11 on ARM do not include the 32 to 64 bit bridge DLL (typically located in c:\windows\SysWOW64) in order to allow 32 bit applications to access USB devices on a 64 bit OS (and Windows 11 on ARM is 64 bit only), he promised to get back, but I haven't heard anything from him since about a week. I will ping him.
Also I will try the project bureau scripts that translate the .JED into a .SVF. These are python scripts. And then I will try to play the SVF file via openecd to program an ATF1504. If this works I would no longer need ATMISP, next week I should find some time to test this.