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.
Don't Panic. Please wash hands.
  • The only functional pin on the data CPLD I can't find connected is pin 4

    That's part of the serial link between the two CPLDs, used for implementing autoconfig: The 144-macrocell CPLD does not have any data lines, but all the required address lines. So in order for logic to answer with data to an access is to shift the data into the data CPLD and then terminate the access. So the data CPLD does not only pass/latch data to/from the Amiga, but also implements a shift register, which must be able to drive both the CPU-side and the Amiga side (note that Autoconfig also works when the card is in "memory only" mode).


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


    and wait for it...

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

    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.


    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?


    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


    Noise would really indicate that something in the CPLD itself is wrong. The pins are configured as "keeper", which is the Xilinx way of "faking" an input hysteresis, but it really helps getting the board stable with ageing power supplies (and sometimes even with Keelog/Electroware PSUs, which I highly recommend to send back due to false advertising claims).


    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.

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


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

  • I've already patched a couple of vias that were open and filled with that copper-oxide looking green gunk

    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.

  • 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
    #3 #17
    #4
    #95 (now fixed)
    #97 #2


    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.

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

    I confirm that these three links are point-to-point links between the CPLDs.


    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've thought about this yesterday when I ordered the mass-production batch of ACA1234 boards. If solder stop is not enough to protect the walls of the via drill, then maybe ENIG (gold) helps making the product more durable. Not that I would encourage anyone to clean the board with water, but I know that customers who live close to the coast have frequent trouble with their Zorro slots because of the salty air. So in short, I decided to make these PCBs ENIG instead of HAL, although technically not needed and I know that the surface treatment is applied after solder stop has been applied. Still, if there is an open via left, it'll get some of the gold, protecting the copper. Further, the open solder holes for JTAG and FPU will be better-protected.


    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.


    It'll be summer until these are available; chip-shortage is biting me. Even confirmed delivery dates are getting pushed around for standard LVTTL logic, and RAM prices are on their way to the moon.

  • 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

  • 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

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

    A direct neighbour pin of the D31 pin on the A1200 side is GND. However, your last test with the wire link from D27 confirms that there is no physical short, as in that case, the D27 input section would also see GND only.


    So yes, this is the final verdict about the 9572XL CPLD. However, to anyone following this: This should be considered an acadamec exercize and not a typical fault location session. If the CPLD would be a several-hundred-dollar part, or the circuit board would be a prototype, you'd surely diagnose it this way, but for a part that you can buy for under 5 dollars and exchange in less than 30 minutes, the "gets quite hot" observation is already enough to put a new one on and see if the card works again.


    TO be honest, I don't want to look into this remote programming stuff, as it would be a one-time thing and take up several hours of my time that I'd rather spend on development. Unfortunately, the new PCBs won't be here in a "very short" time frame: Although they are almost finished at the factory (probably less than 4 days), we have to account 2 days for air freight and at least two weeks in customs, as the dept of DHL Express Leipzig is totally overloaded with work. The new prototype PCB for the ACA1240/1260 has been there for 12 days already, with no indication about clearance. They claim that it's a combination of Brexit and Corona.

  • 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

  • I'll take all the materials to the assembly place some time this week. Chip shortage is real - and it's been causing delays and last-minute changes on the ACA1234 as well.