Electronics > FPGA

Programming (non-JTAG) MAX7000 devices

<< < (15/16) > >>

ale500:
My clone doesn't have a cypress chip, it has a FTDI, an Altera CPLD and the LCX245.

Beta_vulgaris:

--- Quote from: migry on September 28, 2020, 09:36:01 pm ---So I have a log of the EPM7032 sequence which the ALL03 programmer applies to the device to confirm its ID, which of course it fails to do.

So I have wired up a perf board with a PLCC44 socket, where each pins comes to a row of 44 turned pin header for connection. I then found a 5V Arduino, a Nano, which has more or less the required number of pins.

Yesterday. I was able to code the data from the previously posted file into the Arduino sketch in order to generate the waveforms that would be applied by the ALL03 programmer. I then hooked all the programming pins (thanks once again to the site http://matthieu.benoit.free.fr/ ) to pins of the Arduino. Turns out that "analogue" pins named A0 to A5 can be used as digital, but not A6 and A7 - guess which pin I used for a critical signal! I was able to confirm that when the Vpp pin was taken over about 11V the chip went into test mode and previously clamped shift in data now had no contention and was the right level. I scoped the 2 suspected shift out pins: SDOUTA and SDOUTB, and they had identical waveforms which were defintely the EPM7032 responding to the stimulus.

Today. I wanted to properly capture the response. I didn't quite have enough pins, so I moved some stuff around. Mistake  :( . When I raised Vpp from 5V to 12V (which was OK yesterday) I was getting current clamping on my PSU, and a burning smell  :-DD . After some messing around the lights (of  the Arduino went out). Oops! Turns out the min hub (to which the Nano was plugged on) no longer was lit. When tested elsewhere the min hub appeared to light up, and the Nano too. The hub connected to the back of my Dell monitor. The EPM7032 was very hot, and clearly I had blown it up. I eventually figured out that you must ONLY connect Vpp when a number of other inputs are grounded, and appear to put the device into a state where Vpp does not destroy the chip, however I am not 100% sure which pins are the critical ones.

So I ripped out all the wires from the Nano to the EPM7032 board connector and started again. After the usual debugging and discovery of swapped wires, I got the same waveforms on SDOUTA and SDOUTB as yesterday. I used my Rigol scope logic analyser to capture the waveforms (attached).

I also confrmed which pins become outputs and which inputs when Vpp puts the EPM7032 into "programming" mode.

NTPW - input
MTIN - input
SCK - input
SDINA - input
BE - input
BEM - input
SS - input
SBI - input
TM - input
A0 to A6 - input
SDINB - input
SK - input

Vpp - needs around 12V to put the device into test mode (but ONLY do this if the other pins have been set!)

SDOUTA - output
SDOUTB - output
SCOA - output
SCOB - output

--migry

--- End quote ---
EPM7032/EPM7064 in PLCC44 package have different non-ISP programming pinout?
References: http://matthieu.benoit.free.fr/120.htm

c64:
So, you found a dos software which talks to a programmer via LPT port. You are running it in dosbox and managed to intercept all requests it sends to LPT port. Is it correct? Now you need to send all data to the real MAX700 via com port.

You could run it in virtual box which supports dos and can have virtual com port. Not sure it your LPT port hacking will work under virtual box

edevaldo:

--- Quote ---I wonder if someone who knows for sure can confirm that - if the security bit of a "S" type device has been set, can the device be erased by means of JTAG only, or as @bingo beleves, do you need a "parallel" mode type programmer to clear the security bit and erase the device?
--- End quote ---

Yes it can. The security bit does not prevent erasing. But there is a programming option to disable JTAG and make the pins available for IO. Used devices, particularly in lower pin count packages, are usually programmed to disable JTAG. When this happens you need parallel (not the port) programmer like the hilo to put the device back in a erased state and make t he JTAG pins available.

You are getting really close to it. Just fantastic.

edevaldo:

--- Quote from: migry on October 28, 2020, 04:38:54 pm ---My point was that adding the extra circuitry to convert the non-JTAG device to the new JTAG equivalent would add many more extra flops, as compared to the 32 which form the basis of the device as "seen" by the end user.
 
To implement JTAG you need at least 4 flops for the state machine, one for the re-timing of TDO, at least 4 for the instruction register, 32 flops if you implement the Device ID register, plus any addition flops to tie into the old programming circuitry.

From my experiments on the non-JTAG EPM7032 there are at least two shift registers each 10 bits long (so this requires 20 flops). So even in the non-JTAG design there are more "hidden" flops needed for programming, than the 32 which are used by the end user.

[Edit: I originally said 16 user flops and not 32!]

--- End quote ---

A macrocell is a really complex piece of circuit. And you need high voltage circuitry to program each eeprom bit in the device and there may be hundreds or even a few thousand of them. Once read they may ned need to be latched somehow... For the different product terms you can select 16 or more inputs, then there is the expansion terms, optional routing, IO configuration, polarities, select clock and reset sources for the flops...

The additional circuit for JTAG is nothing by comparison. CPLDs may be even worse than FPGAs, and they need thousands of transistors to implement each logic element.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version