I'll revert to my monthly polling
Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
I'll revert to my monthly polling
I've pinged you a couple of email replies over the past month about this. Assumed you were busy with other stuff, but just in case they weren't getting through, I'm ready to give a CPLD repair board a shot, just contact me when you're ready to arrange the logistics.
I'm overdue a nudge on how the CPLD repair boards are coming along! ...
I'm nearing completion of my 'other project' (A4000 repair... https://hackaday.io/project/18…onal-fault-finding-repair)
and may well be moving back to my A1200 and, hopefully the aca1233n-55 too!
All the best,
Hello Jens, me again!
Just checking in approximately 1 month later to see how the CPLD boards are coming along. Willing customer/tester here, ready and waiting for a aca1233n-55 data flavour CPLD, as and when they're ready!
No worries if it's going to take some time. I have a poorly A4000/040 on my desk I'm working on to keep me busy while I wait to fix the aca1233n-55!
Great news, thanks Jens.
Sorry to hear about the chip shortages, seems to be causing pain in lots of industries!
Thought I'd check in +1 month to see if there was any sign of your CPLD boards yet?
All the best,
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...
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,
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:
Appreciate this would only be a one-off though and isn't relly scalable to other customers (like your plan is!)
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:
|Data CPLD Pin
||Address/Clock CPLD Pin
||#95 (now fixed)
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.
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.
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...
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.
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.
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
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.
(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.
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...
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!
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!
"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:
FC0 (not FC1 as mentioned on Friday, that one was fine!)
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,
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.
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!
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,
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?)
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!
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.
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!
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.
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!!
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.