Posts by graysters

Yes, agree this is an academic exercise, more an excuse for me to learn about how these things work whilst sorting out the logistics of a replacement (programmed) part... and giving me an excuse to buy more test gear! That said, the process also uncovered lots of other problems on the board in the mean time, so far from a wasted exercise.

Totally understand on the remote programming stuff. I'll wait patiently for the CPLD PCB's to arrive. Sounds like the estimate is 'about a month' rather than 'many months', although appreciate customs is the unknown factor here...

Cheers,

Graysters

Right, latest update. the correct JTAG cable arrived today, so I fired up TopJTAG probe and started wiggling pins while monitoring, both on my scope and through the JTAG chain itself).

Looks like I was in the right ballpark with D31 on the local bus (data CPLD pin 94), but it turns out this side is just fine. Wiggling D31 on the local bus (and all other local data bus pins from the data CPLD) is reflected both externally via scope (measured at the FPU socket), and internally via JTAG chain.

The problem is actually with D31 on the A1200 bus side of the CPLD. Pin 52 to be precise. I've not exhaustively tested all pins of this bus, but of the pins I have tested, wiggling is reflected externally (seen on scope) and internally (seen on JTAG chain) on all pins *EXCEPT* D31.

Driving D31 output high does not result in either the D31 CPLD input going high, nor is there any movement externally (measured at the expansion slot):

(Red circles show where I'd expect to see the activity on the output trace reflected, but clearly don't)

Just for fun, I also tried driving the (tristated) D31 pin with nearby D27, just to see if it was only the output driver, or also input receiver part of the I/O circuit that had died...

No movement on the D31 CPLD input, but wiggling was now observed on my scope at D31 on the expansion slot which tells me it's not a short to ground on the board... So, it looks like both input/output paths on Data CPLD pin 52 are dead! That certainly tallies with my earlier observation that transfers from the A1200 bus to the local bus were missing D31, it's just the failure was on the way into the CPLD, not out of it.

So yes, I guess the short version is 'Yep data CPLD definitely dead!'... cause of death?.... if I had to guess... maybe a rather catostophic ESD event on that pin when the previous owner shifted it between machines?

Sorry for the long winded waffling debug log. But hopefully the failure analysis may be of some use.

I'll now eagerly await availability of your mini CPLD boards in order to get hold of a replacement data CPLD... Unless you would be willing to give a secure remote-programming session a go? Let me know and I'll get my fresh XC9572XL soldered on!

As an aside... the packaging for the *single* XC9572XL CPLD I ordered is seriously impressive/overkill...

(A1200 for scale... )

That's a whole 90 capacity IC tray vaccum packed with dessicant for a single CPLD! I guess that's the IC travel equivilent of turning up for a flight and being bumped up to first class on an empty plane!

All the best,

Graysters

Quote from Jens

Also, I decided to put that small rectangle in the center of the production panel to good use:

This little board lets me apply power with aligator clips on the mount holes and program a CPLD (44- or 100-pin, not both at the same time) with JTAG. I can then sell the whole board with CPLD as spare part - in your case with a programmed Data CPLD. Only power and JTAG pins are open in the stencil, so de-soldering is easier. The whole thing is flat enough to be shipped in a normal envelope, maybe even slipping through customs.

What an awesome idea Jens!

Sign me up straight away as a beta tester/customer number one for this!

I was ruminating on how best to get a new, programmed data CPLD for this board, given that returns from the UK are a pain right now (I've spent far longer than I care to admit learning about outward processing relief, and other customs jargon before concluding that the system appears broken for an individual using standard couriers)

I actually bought a replacement XC9572XL to check the feasibility of me paying you to remotely program the thing over a VPN, whilst keeping the jed file secure. It looks doable and is a supported feature of iMPACT (i.e. I setup the JTAG programmer connected to the board here, and run cse_server, you run iMPACT at your end and point it to my IP address:

https://www.xilinx.com/support…_remote_configuration.htm

Appreciate this would only be a one-off though and isn't relly scalable to other customers (like your plan is!)

Cheers,

Graysters

Quote from graysters

Aha, interestingly that one is open too. I'll double check this, and try and locate the open. I've already patched a couple of vias that were open and filled with that copper-oxide looking green gunk, so suspect one of those is the culprit. Couldn't see a trace from the data cpld, but guess it runs under the chip and via's out underneath it

Now fixed... The open via was under the (now well and truly voided!) warranty label. No change in overall system behaviour though.

Am I right in saying there are three signals making the serial link between the CPLDs? So far I've found:

I assume one of those is a clock (seperate to the main CPU clock) driving the data CPLD, as I couldn't find a connection from the Address/Clock CPLD CPU/FPU clock output (pin 58) to the data CPLD.

Quote from Jens

That sounds like water - you don't need aggressive flux to oxidize copper to a degree where it gets green and non-conductive. Still, with the vias covered with solder stop, I wouldn't even expect too much trouble even if the previous owner tried to clean the board with water.

Could be water I suppose. The problem is that it appears in some places on the board, the solder stop doesn't completely cover the centre of the via, and you get a tiny hole through which the flux/water can enter. the worst affected vias, and where I've found the opens, are those that were underneath the clear labels holding the patch wires down. I guess the liquid wicked underneath the label and was trapped in the vias with no easy way to evaporate away.

Quote from Jens

Pin#4 is connected through R13 to Pin#95 of the '144.

Aha, interestingly that one is open too. I'll double check this, and try and locate the open. I've already patched a couple of vias that were open and filled with that copper-oxide looking green gunk, so suspect one of those is the culprit. Couldn't see a trace from the data cpld, but guess it runs under the chip and via's out underneath it...

Quote from Jens

Your bodge wire connects CPU clock to FPU clock. That's not a standard connection; the FPU clock is only equal to CPU clock if you close the FPU clock solder-jumper on the top side of the board (just above the oscillator space). If the oscillator is assembled, then you're shorting the oscillator-out with the clock-output of the main CPLD, possibly damaging the '144.

I made the connection this side and have bridged the FPU clock jumper for simplicity, and to allow easy probing of clock at the FPU socket, so for now on this board FPU clock=CPU clock. Totally agree that adding an oscillator for the FPU in this config will likely break something, so shaln't be done. Helpfully, the 12V supply wire for the existing 55.5MHz crystal going through the pin-hole prevents addition of this, so we're safe for now. I may rewire this 'properly' to the CPLD output side of the FPU jumper once everything is up and running.

Quote from Jens

Local D31 flappin' in the breeze at least indicates "not shorted anywhere". Or is that yellow noise line not D31, but the flat green one?

Flat green (logic 0) one is D31. The yellow 'noise' one is actually the clock on analog channel 1 (as measured at the FPU pin) It looks like noise as time base is at 5us/division, zoomed in it's much cleaner.

Quote from Jens

The local D31 should be connected to:

Pin #94 of the data CPLD

Pin #23 of U4 (SD-Ram Data bus driver)

Pin #N1 of the CPU

Pin #J5 of the FPU

Display More

I think I found all those connections on my first pass, but will go and double check all of them, and check for any shorts to anything nearby.

Quote from Jens

(and sometimes even with Keelog/Electroware PSUs, which I highly recommend to send back due to false advertising claims)

Those things aren't going anywhere near my Amigas.

Quote from Jens

All those open connections on your baord are weird. I don't see that the CPU has been removed (or at least it was very nicely soldered back). I have no idea how so many traces could fail - even if some aggressive cleaning fluid had been used, the solder stop should have protected the board.

Isn't it just weird?! I wonder if the previous owner made an attempt to remove the CPU after an initial problem with the board, maybe they couldn't desolder all the pins (problems heating up ground planes etc.) and gave up, leaving a liberal amount of aggressive flux on the board and under the CPU...

Naturally, none of this was disclosed by the seller, it was claimed the board was working up until the regulator was knocked off fiting in a new case... That's clearly not the whole story, and I guess my fault for being too trusting. but makes me all the more determined to get this up and running...

Quote from Jens

Pins and routing space in the CPLDs are always scarce, although the Xilinx 9500XL series has LOTS of resources if you compare to other vendors. ANDing the two function code lines gives me a "CPU access" signal, cutting lots of equations in the SD-Ram controller and the async access controller in half, as they often have a "not CPU access" term.

Clever! Sounds like it's well worth the board space for a commonly used term!

Quote from Jens

However, I frequently end up with about twice the size of manual routing/placing instructions in the source compared to the actual logic, because chip utilization is so high. The fitter will find a fit after hours of attempting, but that usually doesn't meet timing.

Even Peter is often baffled by the amount of functionality I can cram into these chips with manual routing, and he's our master of making low-cost FPGAs do things at speeds that are often only possible with the next-higher speed grade

Consider me impressed! I've not played with manual routing on CPLDs. But I've been pleased with how much functionality you can squeeze into these things. A previous project I was on required the use of a CPLD to both convert an incoming SPI bitstream on the fly (signed->2s compliment) and seperately monitor another serial output for a 4 bit number representing a detected 'keyword' (this was an increadibly low power ASIC speech recognition demo). The initial spec used the smallest coolrunner-II CPLD from Xilinx, and was only going to display a hex number representing which of the 16 words were detected, but with some heavily optimised verilog, I was able to (only just!) fit in a fairly sophisticated text scroller in there that pulled and displayed the exact word from a lookup table!

Quote from Jens

"down there" it's only data lines and clock port stuff that's 1:1 from the connector. Most (if not all) of the connections are direct to the CPLD, and I have my doubts that you find a bad connection there

Understood, and I think I've traced everything to the data CPLD anyway. The only functional pin on the data CPLD I can't find connected is pin 4 (function block2, cell 2 of the CPLD), all others appear used, or specified N/C in the datasheet.

Anyway... some further progress...

Thanks to your PCB image, I've identified and fixed (I believe) all the opens around the CPU pins, which were:

D1

D13

D18

D19

FC0 (not FC1 as mentioned on Friday, that one was fine!)

DSACK0

A30

and wait for it...

CLK.. (Seriously... I *really* should have spotted this one sooner!! )

I also found and fixed an open on D28 from the expansion slot to the data CPLD (shown in topside board pic below).

At this point we've now progressed to a red screen when powering on the A1200 (previously black screen), so I've fired up my shiny new Rigol MSO1104Z and started probing around at power-on. I'm seeing lots of activity on the address/data strobes and data lines on both A1200 bus, and on the local 32bit bus, which would seem to confirm at least a semi-functional Data CPLD routing stuff back and forth. However the first potential Data CPLD issue I see is on D31 on the local bus where I'm seeing no activity (constant logic 0). All other data pins seem to mirror exactly what is seen across both busses (i.e. A1200 D0 = Local Bus D0, A1200 D1 = Local bus D1 etc..) Changes on the A1200 bus D31 do not appear on the local bus D31. I've checked for shorts on this pin to VDD/Ground, and it appears isolated.

(note pulses on the A1200 bus D31 are not reflected on the local bus D31, whereas D25 and D27 match across the busses)

Unless there's something special about the upper-most data bit on the local bus, my current working theory is that some part of the I/O driver on this pin in the CPLD (pin 94, function block2, cell 2. Shown below) is shorted internally and sinking a load of current (hence the heat given off). I'll be able to confirm once the right JTAG cable arrives and I can try specifically wiggling this pin...

(Suspect CPLD Pin highlighted, A1200 Bus D28 bodge wire also shown!)

Anything else worth checking/probing for while I wait for this (second!) JTAG cable?

Thanks as always,

Graysters

Quote from Jens

That's because the "highest address line" can be selected with R11 or R10: R11 will pass A30 to the controller CPLD, and R10 will pass A27. This allowed me to check the ACA1233n design with the ACA1233 CPLD code before I started developing the Z3 autoconfig part, which is implemented "kinda weird", as it's distributed over two CPLDs with a serial link between the two. In development, you want to test in small steps (called "unit testing", but already practised by Werner von Braun when he sent the first rockets to space).

That makes perfect sense. Building on something that's known working, one step at a time. So if (when) something breaks, you limit the scope of what you need to debug.

Quote from Jens

Right, I won't open the schematics, but this should help you tracing/repairing connections

Jens, Thank you so much for this. that helps enormously, and confirms a couple of suspicions around unused pins, and also that FC1 CPU pin is currently open and needs patching.

I noticed that FC0 and (I suspected, but I now know FC1) go to the discrete AND gate U14 before heading into the CPLD... so did you run out of pins, or logic in that CPLD?

One last request for now... could you share the same style image, but showing the lower half of the expansion port connection (just to check for opens that may be lurking under the plastic connector?

Thanks again! This is really first rate support!

Best Regards,

Graysters

Latest update:

Urgh... This board is in an awful state. Whatever was spilt and left on the board has damaged a number of traces to the CPU pin vias, on both sides of the board... I have been tracing the various signals between the CPU, the 'Data' CPLD and... Address/clock/other magic? CPLD and think I have patched up the data bus signals and address lines, though can't find a CPU->CPLD connection for [A27:A29] & A31, not sure if these are unused as it's outside the 128MB address space? (Though I note A30 goes from CPU to CPLD via resistor R11). Where I'm struggling is identifying opens on traces & CPU pin connections that are *underneath* the CPU.

I won't presume to ask for a schematic, but to at least save me having to de-solder the CPU, I would be ever so grateful if you could share a photo/image showing the top-side of the board around the CPU so that I can at least visually trace the signals running under the CPU, and patch any remaining opens.

All the best,

Graysters

Quote from Jens

First of all, the picture you've posted shows more than "corrosion" - it appears like mechanical damage, but that green-ish residue looks like the thing has been stored in a humid basement for years.

Indeed. Not pretty is it? Amazing how it got so bad in such a relatively short period (5 years tops, right?)

Quote from Jens

Data pins of the clock port are unbuffered CPU data lines. If they are shorted "somewhere", the computer won't start. And it may also explain why the data CPLD is gettig hot.

Noted. Right, I'll get probing!

I've put the FPU to one side for the minute, and returned to the board, and there's a small amount of progress... I managed to get hold of a stereo microscope to check out the soldering a bit more closely. (pics below are just with my camera, I tried a 'through the microscope' shot, but it wasn't particularly clear). First I took a look at the FPU socket....

It's far from a perfect solder job, but not horrendous and crucially no obvious shorts to any traces... however, I took a look at the expansion slot connector soldering and was struck by significant corrosion due to (I suspect) rather liberal application of flux which wasn't thoroughly cleaned off (not saying this is due to icomp! It may have been 'overspill' when the FPU socket was soldered by previous owner!). I've given it a gentle clean with IPA, and the damage is mostly just stripped solder mask, but in probing, I have found 3 shorts on the traces that snake around the pins. 2 of these appear to be data pins that go to the clock-port, which shouldn't stop the card starting, so I will tackle at some point, but a third was from the reset pin(!) so a bit more crucial!

I've now added a patch wire to reconnect this.

No change in behaviour when re-installed though (testing at various mm of extraction as usual!) There's no other obvious issues on the back-side of the board, but I've yet to do a full 'ring out' of the expansion port connector. My concern is that the corrosion may extend to the top side of the board which will be a pain to get to as it is under the plastic expansion socket connector against the PCB. I don't particularly fancy desoldering the whole connector! I will try and trace all the wires I can see on the topside first...

On the JTAG front, there's a limited amount of progress... The JTAG cable I ordered arrived but frustratingly... it was mislabelled by the seller as a Xilinx platform cable, but is in fact a Digilent JTAG-USB cable, which only supports basic chain-tracing for XC9500(XL) series CPLDs, and not much else. However, with this, I was able to do a chain test in iMPACT, and both CPLDs do indeed show up:

That's more than I expected, and tells me that the data CPLD is not entirely dead... though, given how much hotter the data CPLD is than the other CPLD, even when just sat idle, I still strongly suspect a fairly fatal internal short necessitating replacement!

Anyway... New JTAG cable ordered from a seller that assures me that it's a genuine clone of a Xilinx platform cable (if that's not a contradiction in terms!) This should be compatible with JTAGLive or Topprobe to allow me to wiggle the I/Os and see exactly what's working or not...

Determined to revive this board!

Thanks Jens.

Yes I think I saw some of the same Aussie's Youtube videos which convinced me that the scope should be OK. Obviously not up there with the Agilent/Keysights, but seems to have everything I think that I could need for a while at least.

Thanks for the suggestion, I'll have a good inspect around the existing FPU socket soldering. Could probably do with a decent stereo microscope... hmm I feel another purchase coming on!

Interestingly the card came with an FPU installed in the socket, but I removed it to help with debug (Obviously the board is still not working with/without it). I did note that the FPU clock jumper had not been bridged (and by the looks of it had never been). Given that the 12V supply wire prevents a crystal easily being installed, I can only assume that the FPU was never used as it would never have got a clock! Odd.

I might have a look at the supplied 'FPU' chip in a bit more detail, at least to see if any of the common pins (e.g. ground/supply) have continuity where expected based on the 68882 pinout. Just to check it's not obviously an outright rebadged different chip. Here's a pic of it. I doubt there's any easy way of telling by it's exterior whether or not it's obviously a fake?:

Anyway, I'll inspect around the FPU pins this evening and wait patiently for my JTAG cable to arrive to debug further.

Thanks again Jens for your support. It's very much appreciated.

Hi Jens,

I was looking out for an Agilent scope, like the one you mentioned, but in the end I managed to get hold of an ex-demonstrator model Rigol MSO1104Z-S (mixed signal 4ch ana/16ch dig, 100MHz 1GSps), for a particularly good price, so went with that!

I also have a Xilinx (well... 'compatible') platform cable usb JTAG adaptor on it's way to me to check out the JTAG chain, to see if there's any life in the CPLD(s), but my suspicion is that the data CPLD at least is, to use a technical term, 'knackered'!

In the mean time, I fired up the scope to get a better look at the crystal output. Seems like a fairly solid 55.5MHz signal coming from it, so I suspect we can rule that out as the issue (see below)?

While I wait for the JTAG adaptor to arrive, Is there anything else on the board worth probing with my new scope, to assist with the debugging my end (any pins on the other CPLD by the crystal worth probing for signs of life)?

I guess it's just putting off the inevitable, but as I'm sure you can appreciate, I'd rather be doing something practical at my bench, rather than scratching my head trying to work out how to navigate shipping companies and customs to be able to get this board to you and back without incurring the full board value VAT cost on the way back!

Hi Jens,

Quote from Jens

If you can do a boundary scan and wiggle on each pin high/low, read it back and compare what you've written - that would make things easier for us, but since there's nothing you can do to repair it (the jedec file of this chip is not public), it'll come down to "ship to Germany" anyway.

I'll see if I can get into the office to try this out, but I guess if one of the CPLDs is sufficiently broken, the whole JTAG chain will be broken so scan may not tell us anything other than 'something's broken'. As you say, the net result will likely be 'ship to Germany' anyway, but if I can help in the diagnosis process in anyway, I'm more than happy to.

Quote from Jens

If you can, please measure the 55MHz oscillator. You described mechanical damage before, and you have to treat these oscillators like mechanical parts. They are sensitive to shock and will fail if they're falling hard

With my limited home testing equipment (100Msps logic analyser), I've ascertained that the crystal output is oscillating at around 50MHz(ish).. so I can believe it is running at 55MHz but can't get much more accuracy until I get to the office... That said, I'm very close to ordering myself a decent oscilliscope to do this sort of thing at home... this might just push me over the edge to ordering one!!

Quote from Jens

The 9572XL chip is 4,70 EUR, and exchanging the chip including JTAG programming is 28,- EUR. Plus your local VAT plus shipment (DHL actually charges an extra Brexit fee!), will still be much cheaper than a new card. However, this is only an estimate based on the assumption that only the data-CPLD is dead.

That seems more than reasonable, and I'd be more than happy to pay this for (or x2 if both CPLDs need replacing), so I would be happy to proceed with this.

Cheers,

Graysters

Hi Jens,

Any insight into the board's history from the Warranty ID? (VT4F3). Would it be worth me waiting till I get into work to hook up via JTAG to check the CPLDs, or just look to return for repair? I can probably source and replace the CPLD(s) myself, but obviously the magic is in the jed files, which I totally understand you're not going to want to be sending out!

I've started looking at the customs situation regarding UK->EU->UK repairs, and it looks like the VAT/Duty can be kept to a reasonable level by using 'outward processing' which seems specifically setup for exactly this situation. Details here:

https://www.gov.uk/guidance/us…cess-or-repair-your-goods'

Based on this it seems that the VAT/Duty is payable only on the cost of the repair (and postage/packing), rather than the full price of the repaired goods. I just need to look into the paperwork

If you could let me know what the cost of repair would likely be (either here, or by private message), I would be most greatful.

Thanks,

Graysters

Hi Jens. Thanks again for the swift response!

The regulator is measuring 3.294V, so doesn't seem too far off. Regarding JTAG access, I might have been able to do this... if I could get into the office, (I'm an ASIC implementation engineer, and have done a little Xilinx CPLD programming myself... but I'm nowhere near an expert!)

Warranty ID is VT4F3

Sadly I'm in the UK (Cambridge).... so I was in Europe until about 6 weeks ago... I certainly didn't vote for Brexit!!

I'd still be interested in exploring a repair if the price is reasonable and customs can be negotiated.

Cheers,

Graysters

Hi There!

I have recently purchased a second hand ACA1233n-55 which is non-functional. (This was the one that I mentioned yesterday had the damage to the cap C85, which has now been replaced, along with the 5V regulator, thanks to Jens pointers as to the value of the Cap!)

Having successfully sourced and replaced the C85 cap, the board is still not working (blank screen, power light on, but no other activity), even after various cleanings of the connector and repositioning the card. (I also have a working ACA1221 which works fine, so I don't suspect the edge connector being an issue.)

One thing I did notice was that the ACA1233n CPLDs were getting very warm to the touch with the power on. Not 'too hot to touch', but certainly 'uncomfortable to hold your finger on!' The one by the CPU slightly hotter than the one by the crystal. I wanted to check whether that was normal, or a likely sign that the CPLD(s) are faulty, or whether it might point to another issue I can investigate?

As mentioned yesterday, this card is second hand and totally out of warranty. The chap I purchased this card from assures me that it was working prior to the cap and regulator being knocked off, but I obviously can't prove this. Would love to get this working if I can, but wanted to check whether continued debugging effort was justified.

Out of interest, do you offer an out-of-warranty repair service on these cards?

Cheers,

Graysters

(FWIW this is with a recapped B2 motherboard A1200 with timing fixes applied and powered by an original Amiga 500 4.3A supply.)

Thanks for the quick response Jens!

Very much appreciated.

In case it's not obvious, this card is no longer under warranty, and clearly any repair atempt is at my own risk!

Hi There,

I have a ACA1233n-55 that has sustained some damage to the capacitor C85 during fitting (the one that the additional 5V regulator is attached to), as such I am looking to replace this capcitor, and was wondering if you would be so kind as to tell me what size/value capacitor I should use to replace it with.

Many thanks in advance!