- tflogoboard.png (40.77 KiB) Viewed 3257 times
- SingleShot0000.jpg (68.77 KiB) Viewed 3257 times
So!.. Here's a list of issues i've run into and stupid mistakes i've made, as well as any advice. I'll update when I think of something:
- Watch out for shorts between pads and the ground plane. This is especially bad on boards with crappy solder masks. As you can see in the image at the top, one of the pins has solder over-running the pad and making contact with an exposed bit of ground plane. It took a microscope and a good deal of time probing around for me to find this. Infact i'd already moved on to making a fresh board before I realised the problem, so now I have 1.5 TF530s. If you're lucky you'll find this by testing for continuity between the ground plane and a data/address pin, but this could theoretically occur between adjacent data/address pins (though I think it would be easier to spot visually). Always check 3v3, GND, and 5v for continuity before testing. Preferably after each major component is added.
- Stupid mistake number two: This one really is embarassing. There are three places on the 530 rev3 board that look to take 0603 SMD components. If you've bulk-ordered your parts you'll find you only have one set of 0603 components and these are 0.1uF capacitors. If the solder mask is bad, it might seem reasonable to put these caps at each 0603 sized spot on the board. This is a big mistake, as one of these pads (next to the ram CPLD) is for a dummy load resistor to try to absorb reflections on the clock line, and is labelled RCLKLOAD. It does appear in the BOM, so this mistake is on me, but I can see it being repeated by a lot of builders who don't take the time to match every pad with the BOM. The result was that I had a non-booting board. I actually stumbled onto this mistake whilst trawling over the board in eagle, and felt like a right idiot. After removing the cap the board booted first time.
- As Stephen has said time and time again, you absolutely need a microscope to build any of these things, and an oscilloscope is preferred. An oscilloscope you can take a single trace on is also better (so you can see the CPU wiggling the data/address lines in the first second or so, if it then hangs afterwards). I have a cheap chinese microscope that I absolutely could not have built this thing without. It is a must!
- Bring the board up gradually, do not add all the components and hope for the best. Even leaving the bypass caps off is ooookay at first. Once you have something in diagrom, test after each major component in diagrom and keep a journal of the order in which you add components. This will help you to identify any problematic pieces. For example, in my final build I was able to determine that I had a solder issue on I8 immediately, because everything was working prior to me adding it. Seems obvious, but i'm sure people (like myself) jump the gun on this.
- Check all pins for adjacent continuity with a DMM. If everything looks fine and the CPLDs program but you have a non-booting system, it is likely due to ripple on the 3v3/5v or CLK lines. As Stephen has said, the 530 is very sensitive to reflections on the CLK line. Check the relevant pins using a scope and single-shot to see if the CPU is doing anything at reset. Which brings me to...
- Your CPU is not dead. This is absolutely the single most tempting thought that I think goes through peoples minds when building one of these cards. 'It isn't working, but everything looks good, the CPU must be a dud'. No. No it isn't, lol... If you get a red screen or something, then fine, but if all you're getting is no life at all then the chances of this being CPU related are faaaaaaaaaar and away less than the chances of it being your soldering, or a noisy line somewhere. I know how tempting this line of thought is from experience - just try to resist it. You're building this thing yourself with dozens upon dozens of solder joints - the chances are you've made some small mistake. Even the fake re-screened EC40C I received in the post is working just as well as my 100% genuine NOS EC33C.
- Having a vice or something to gently hold the board whilst soldering under the microscope is very handy. You don't want to be using one hand to hold the board in place while you chase it around with your other one. Have the board secured somehow, and use two hands to steady the soldering iron if necessary whilst drag soldering.
- Make sure you do practice, and master, drag soldering. I've done CPLDs like this in the past with a needle-tip one pin at a time. it yields okay results, but takes forever. It's difficult at first to get the drag method down, but when you do you'll be very grateful that you learned! It doesn't take long to get to grips with it. It's about the amount of solder, and the angle at which you sweep the tip down the edge. As you know Stephen has some good videos on this.
As for the IDE issue - I have discussed this in another thread as you may have seen, however having looked into the problem in detail i'm still somewhat stumped. I can transfer files greater than the maxtransfer setting - something on the order of 200-250k when the maxtransfer is as low as 100k, yet I cannot transfer anything bigger than about 250k. What happens is not corruption, but a hung 'busy' cursor and upon reboot a 0 file size.
I realise this sounds exactly like a maxtransfer problem, and so i've been trying to test for that and think I may have ruled it out? I have used both the SD2IDE card as well an old (but working) actual IDE hard drive, with the same results. I have tried a standard 3.1 install, with only a 500MB partition with the same results. I've used every patched scsi.device, as well as SFS, PFS and pfs3aio (PDS?) with the same results. I have tried very conservative maxtransfer sizes of 0x1A00 to 0x1FE00 with the same results. Interestingly on small enough partitions and a real IDE disk, transfers greater than the maxtransfer work fine up to around 200k at which point it just freezes (sorta, the system is still responsive).
I can read any file just fine, of any size. I can use UAE to copy over whatever I want and run it just fine on the Amiga side.
I can live with this. It isn't particularly inconvenient for me and as soon as I can get hold of a PCB i'll be moving to the 534 anyway, but if this isn't a 530 related problem (my specific 530 that is), than I really can't understand it from an OS perspective. I'm sure as usual i'm missing something pretty obvious on the OS side, but having trawled through the threads over at EAB i'm still not seeing what i'm doing wrong.
Anyway - like I say this is a situation i am happy to live with for now! Any questions about my build let me know below and i'll try and answer.
Cheers all,
John
- tf530success.jpg (123.81 KiB) Viewed 3257 times
- systest.jpg (53.25 KiB) Viewed 3257 times
