Non-functional ACA1233n (Hot CPLD normal?) query

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.

Don't Panic. Please wash hands.
  • 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.)

  • 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.

    This is a "soft marker" for the CPLD to be bad. Soft, because a Xilinx CPLD does not get "red hot" when it had a latch-up. Please measure the 3.3V regulator near the clock port; the tab is the 3.3V output. If that's considerably lower than 3.3V, it's an indivation that one of the CPLDs had a latch-up.


    For further diagnosis, I normally check the warranty ID and see what else the cutsomer has bought. Reason I'm asking is that the CPLD near the CPU slot connector (and the CPU) is the "data CPLD" that routes the local 32-bit data bus to the A1200 or ACA500plus. We've had cases where an ACA500plus was connected the wrong way round, and an A1200 accel was connected while that happened. This has killed the data CPLD, which did *not* result in a voltage drop on the 3.3V rail. Checking the warranty ID is of course also only a "soft marker" as it only moves probabilities. The only way to tell if the input/output pin is defective is a boundary scan through JTAG, which you probably can't do.


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

    Yes, we do. And for a 55MHz board, it'll surely be worth it. Here's hope that you're in Europe, so customs is not a problem...

  • 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 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

  • Any insight into the board's history from the Warranty ID? (VT4F3).

    The original customer does have an ACA500plus, but also a second ACA1233n-55, so no reason to believe that yours was connected to the ACA500plus while it was connected the wrong way round. Instead, I figure he is just fine with one top-of-the-line 68030 card.


    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?

    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.


    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, for example. This may be something you can replace yourself easily, and I could ship the part in a letter, probably passing customs without being noticed. A frequency counter or an oscilloscope are needed, though.

    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.

    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.

  • Hi 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.


    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.


    Cheers,


    Graysters

  • this might just push me over the edge to ordering one!!

    I still like my Agilent 54622D mixed-signal scope. Only 200MSamples, but analogue/digital mixed and a very small form factor. As a Motorola-fanboy, I like the fact that it's powered by a 68ec020 :-)


    These pop up on eBay every now and then for a good price. It was well worth the 10k EUR that I've paid for it back then, but you should find one of these for around 500,- EUR now.

  • 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!

  • RIgol is probably fine - never used one myself, but my favourite Australian Youtuber endorses them, so I guess they are good in the field :-) Yes, that oscillator is fine.


    I see a picture of this card for the first time now - looks like someone has added an FPU socket. I've had an ACA1233 repair a few months ago (the old red version) where someone has added an FPU socket, and the board didn't work any more after that. The solution was that there was a small (really tiny!) solder whisker between an FPU pin and a nearby trace, that was scratched free of the solder stop. You might want to double-check that as well.


    Another possibility is of course that the previous owner got one of those fake FPUs that contains a totally different chip, which damaged more parts on the board. You never know - the one thing I know is why I stay away from FPUs: Way too many fakes around.

  • 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.

  • I don'T have the same nice overview of mask sets that I have for the CPUs - the only way for me to identify a fake is to measure it's power consumption, which will only tell me if the die-shrink stepping is what the print claims to be. Can't do that from a distance :-)


    Yes, it may be a good idea to keep this out of the socket. The logic will automatically find that it's not in, and tell the CPU that the FPU is not installed (with a BERR, that is).

  • 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!

  • 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!

    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.


    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.

  • 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!

  • Amazing how it got so bad in such a relatively short period (5 years tops, right?)

    The 55MHz card was release in 2019 - as my "semi-comeback" after I almost prepared for early retirement :-)


    Noted. Right, I'll get probing!

    If you really go all the way with boundary scan on the CPLDs, you can take advantage of the 6800 CPU tri-stating it's address and data lines while Reset is low: If you output low on that pin, you can be sure that the CPU won't interfere with your test signals.

  • 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

  • though can't find a CPU->CPLD connection for [A27:A29] & A31

    These are not used in this design.


    (Though I note A30 goes from CPU to CPLD via resistor R11).

    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).


    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.

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

    The "transparency" setting "kind of" makes the traces under the silkscreen visible.

  • 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!



    Best Regards,


    Graysters

  • 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?

    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.


    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 :-)

    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?

    "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, unless someone has removed the connector and molested the PCB badly. If that's the case, then a new ACA1234 will most likely be the better choice.

  • 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:


    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!! :rolleyes:)



    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