Debugging a freshly assembled afterburner

[mr-who2012]

This thread continues the discussion of Issue #23

[mr-who2012]

For now, I just shorted all VIL-pins to GND and tried reading the GAL again. Unlike before, reading is impossible now - even with the -nc-flag.

I'm getting the same result as with reading informations from the chip:

afterburner r -v -d /dev/ttyUSB0 -t GAL16V8 -nc
Afterburner v.0.4
opening serial: /dev/ttyUSB0
read: 5 ''
opening serial: /dev/ttyUSB0
read: 5 ''
opening serial: /dev/ttyUSB0
read: 5 ''
read: 18 'OK gal set: 1'
read: 21 'OK upload finished'
read: 52 'ER unknown or wrong GAL type (check Power ON)'
ER unknown or wrong GAL type (check Power ON)
result=-1

BTW, programming-voltage is 12,4V. During reading and writing pin2 IS receiving this higher voltage. Do you think shorting the VIL-pins directly to ground could damage something? I see no reason using pull-downs for them at all.

[ole00]

Unlike before, reading is impossible now

Well, you did not mention you were able to read before, did you? If you could read then you most likely did not need the -nc flag, unless you had some unsupported GAL.

Do you think shorting the VIL-pins directly to ground could damage something?

I think this could damage the GAL chip.

I see no reason using pull-downs for them at all.

Afterburner is based on GALBlast which uses the pull downs - I had no reason NOT to use pull downs. So far they work OK for the GALS I tried. AFTBlast mentions that Atmel GALs do not need pull downs. However, Atmel GALS do work with pull downs quite well, therefore Aftewrburner uses them. Feel free to experiment with pull downs.

Which GAL do you try to program? Can you post an image of your GAL IC with readable chip markings? Could you also
post an image of your Afterburner? Ideally high res image of the top side and bottom side.

[mr-who2012]

Unlike before, reading is impossible now

Well, you did not mention you were able to read before, did you? If you could read then you most likely did not need the -nc flag, unless you had some unsupported GAL.

Oh my, I really didn't. The situation was like this: At the very first time, I plugged-in my lattice GAL16V8D and afterburner recognized it as Atmel ATF16V8....(sorry, don't remember which letter at the end). Thing is, Atmel needs 10V, Lattice 12V according to afterburner-main-page. Anyway, afterburner reported wrong, but it did output some info. I didn't try writing at the time. I experimented with the voltages and also tried another chip of the same package in the hope, it would report the correct chip. At some point afterburner didn't recognize anything anymore, even when I tried a new "fresh" third chip out of that same package. It was, however, possible writing and reading a chip with the "-nc"-force-flag. At the end of writing, comparing did fail. Reading a chip in such a way resulted in a fuse-map with "1" everywhere.
Now even that is not possible.

So the new thing is: When pulling all VIL-pins directly to ground, afterburner doesn't even false-read the chip anymore. Maybe this is a good thing because the logic-analyzer did show Pin12 (output) as always-high. So that could explains why the fusemap was full of "1". When afterburner now doesn't read the chip anymore...it could be a more "honest" error, all VIL-pins not influencing the output anymore. It could also mean the chip died because directly shorting VIls to ground caused too much current inside the chip.

VIL1 is directly connected to ground anyway (in the board-wiring). Why do you see a risk for the chip, doing the same with the other VIL-pins?

Anyway, I should plug-in the logic-analyzer again and I should try your mentioned pull-up-resistor.
Yes, I can make photos for you. I also want a logic-analyzer-session with all VILs pulled-down with resistors (so undo my VIL-to-ground-hack) and put the pull-up in place.

Please be patient. I also have some computer-trouble right now. It could take a few days. Maybe at some day the other GAL-chips from china I ordered, will arrive. But this might take a couple of weeks. Possible the whole trouble is just about a faulty chip-package.

[ole00]

Actually, could you try to add pull up resistor (10k, probably 4k7 should work as well ) to the SDOUT pin (resistor between Arduino D12 and +5V) . It looks like some chips may need it - it was mentioned in one of the discussions, but I forgot to update the schematics and the rest of the files. This might be the reason SDOUT was always low on your chip. Sorry about that.

[ole00]

I re-read the information you previously posted and realised your SDOUT (pin 12) was always HIGH not Low as I incorrectly assumed. So the Pull-up resistor on SDOUT might not be the solution for your particular case. Anyway, the pull up on SDOUT is required for certain GAL ICs (GAL20V8 specifically) and so far does not negatively affect the programming of the GALs that do not require it. An alternative option is to enable internal pull-up on the SDOUT pin as reported by @ismal

VIL1 is directly connected to ground anyway (in the board-wiring). Why do you see a risk for the chip, doing the same with the other VIL-pins?

Missing pull down resistor on PIN1: That's a very good point. I checked the schematics of GALblast and it does have a pull down resistor on GAL PIN 1. Then I checked the schematics of ATFblast and it does not have a pull down on the pin. So I must have followed the ATF blast's schematics. The safer option is to have the pull down resistor on PIN1 as per GALblast schematics even though it might not be strictly necessary for certain GAL ICs.

Please be patient. I also have some computer-trouble right now.

No worries, there is no rush. I might be away from computed during the next few weeks.

[mr-who2012]

Yea...it's the last week before christmas...:-) I have no computer-time as well...

[mr-who2012]

Hi there and happy new year.
After a long holiday, I finally put myself together to continue researching my afterburner-problem. Meanwhile, the new chips arrived: Lattice GAL16V8D, Lattice GAL22V10B and Atmel ATF16V8B.
So the first thing I did, was removing the short-to-ground-cable, I soldered to the afterburner before. So all VIL-pins are using pull-downs again now (as proposed by the board-design).

Next thing was lowering programming-voltage from 12,4V to 10,1V to make afterburner ready for the ATMEL-chip. Then I inserted the new atmel ATF16V8B. This is the output:

pastebin: ATF16V8B-output

afterburner recognized the new chip - but only if I set it on the commandline. The fuse-map is full of 1 again. Propably an error again? What should a fuse-map of a fresh chip actually read?

For comparison, I tried my old GAL16V8D-chip again. It's the one I used most, in previous testings:

pastebin: GAL16V8D-error

So...this one seems to be broken. Now my question is: What did you want me to do actually? When re-reading old posts, I find:

• high-res photos from board and chips
• MAYBE a pull-down at PIN11 (and breaking the trace on afterburner-board)
• optionally: A pull-up-resistor on Arduino-D12-Pin
• checking resistance of afterburner-pins 13-17 to GND with multimeter
• Logic-Analyzer-Session with...probes re-arranged...somehow...? What shall I actually test with my LA?

Photos and resistance-measurement are quickly done. I will report-back later. Soldering: Not today. LA-session: Not sure what to measure.

Thank you for all the support up to now. Direct-support from the author himself actually is quiet a special service!

[mr-who2012]

Photos and measurements...

[ole00]

Happy new year and congrats to bringing your Afterburner back to life !

afterburner recognized the new chip - but only if I set it on the commandline.

That's correct and intended. There is no real autodetection of different GAL chips
in Afterburner. The detection just checks the Afterburner can talk to the GAL chip
and whether further operations (like read or write) have high chance to succeed.
For the sake of Afterburner's simplicity the GAL type has to be always specified.

The fuse-map is full of 1 again. Propably an error again?

Unlikely. All of the new GALs I got were erased to 1s. When you erase any modern GAL
(and then read it back) all fuse bits are flipped to 1. So this is correct. Still, it
might be a good idea to erase the GAL before the first write even if it reads all ones.

So...this one seems to be broken.

You did not mention whether you've raised VPP to 12 when trying your GAL16V8D.
ATFs need around 10V, Lattice GALs usually need 12V. If you did, then your GAL chip is
probably gone.

Hi-res photos...

I requested them mainly because I did not know whether you had a PCB or whether you
used a protoboard or breadboard. Also, I did not know that your board was already functional.
Looking at the board - I recommend to always clean the flux with IPA. Some unburned flux can cause
capacitance issues on and between pins (not a theory I had such issues on few of my old boards).

optionally: A pull-up-resistor on Arduino-D12-Pin

That is required for GAL20V8B, so far other GALs do not seem to need that pull up resistor.
It has been added to the latest afterburner revision. BTW I've tested the GAL20V8 adapter
design and it works OK.

checking resistance of afterburner-pins 13-17 to GND with multimeter

The values seem OK.

Logic-Analyzer-Session with...probes re-arranged...somehow...? What shall I actually test with my LA?

No need to retest now that it works for you. I was just explaining why your LA readings were not as you expected them to be.

[mr-who2012]

The detection just checks the Afterburner can talk to the GAL chip and whether further operations (like read or write) have high chance to succeed. For the sake of Afterburner's simplicity the GAL type has to be always specified.

Aah...I see, now I understand!

All of the new GALs I got were erased to 1s. When you erase any modern GAL
(and then read it back) all fuse bits are flipped to 1. So this is correct.

Thank you, that's a helpful information.

You did not mention whether you've raised VPP to 12 when trying your GAL16V8D.

Yes, I did. I tried several voltages with the first GAL16V8D. Maybe that's the reason its not working anymore. It's also possible I got low-quality-chips (I bought five chips last year. I had trouble with three of them. Two are still untested).

Looking at the board - I recommend to always clean the flux with IPA.

Aah, you got me! I ALWAYS clean up the flux. This time I was in a hurry undoing the hack and didn't clean-up.

So...as I understand...everything should be alright and ready to go now. That's unexpected. I look forward trying some writing-attempts. Still can't believe it. Will report back...