The Z80 SBC PCB’s finally arrived. They were shipped only 3 days after the 8052 SBC PCB’s but arrived 10 days later. Go figure …
When I was able to sit down and start the build process, I set out to populate and solder a test and development unit. One of the 1st issues I had run across a week ago was discovered, er, uh, realized in a “duh moment” … the pinout for the SD memory card module was reversed from what I had intended. I had originally defined the layout symbol looking from the top-down (component side) orientation, which was fine if I had mounted it on the component side of the PCB but I didn’t. The layout package I am using allows me to “flip” (mirror) the symbol to to bottom side of the PCB layout but in doing so, it also mirrors the pad orientation, which I did not think about at the time. My intention was to nestle the components between the SD memory card module and the bottom of the Z80 PCB, thereby protecting them. I should have constructed another symbol that reversed the pads to use for that purpose but I did not. So what I have to do is mount the SD memory card reader PCB with the components facing out. Not a big deal but ideally, not what I had wanted.
In case there was any rework to be done, the SD memory card module may be in the way, so I decided to leave it off the board for the time being, I have two different types of 40-pin IC sockets. One is a solid plastic frame with no voids in it and the other was a “frame” with voids in the frame so that you can see the PCB under it when the IC is removed from the socket. It was always my intention to use the “open frame” socket for the Z80 since that’s where the SD memory card’s solder pads are located and I figured it to better to be able to get at them than not. However, after the build, I realized that I used the “solid frame” socket type for the Z80. Oops! In my haste, I had forgotten to use the “open frame” socket. I had to desolder all 40 pins and gently lift the 40-pin socket out of the solder holes, hoping NOT to rip any through hole plating or traces up in the process. [The two different socket types can be seen in the reference photos below as well as the removed frame support between pin 20 and 21] All pins and pads seemed clear but after removing the socket, I saw that I had fully ripped the top solder pad off of pin 39 and the single 6 mil trace going to it … and partially ripped the top solder pad off of pin 10 and one of the two 6 mil traces going to it. The rework wasn’t to bad after it was completed. Reference “C” in the photos below.
In mounting the TEENSY module, I found that the E4 and E5 connections were skewed off by 50 mils. I am not sure how that happened because I measured those distances as I was creating the PCB foot-print. Since I used the thin excess lead clippings from the 100 nF capacitors for the connections to the Z80 PCB, the 50 mil difference wasn’t an issue. If it was off by more than 50 mils, it likely would have been.
With those pre-power-up mods out of the way, I proceeded to check the power supply input from power applied via the external power plug, since it powers all circuitry except the TEENSY. In case there was too much current draw from the USB port, which is required for the USB-to-serial interface, I added a means to supply external power via a “standard” 2.1/6 mm “power socket”. I found there was no power to the LM7805 voltage regulator and when I investigated the power socket, I found that the “tip and sleeve” connections were reversed. Since there is a 1N4001 diode in series with the input to the LM7805, there was no electrical damage. I do not recall actually checking that the schematic symbol and PCB symbol matched before submitting the GERBER files to the PCB fab house and that was the problem. I had to cut the thermal reliefs from the “tip” connection to ground and scrape off some solder mask to access the ground plane for the “sleeve” connection but it was a fairly quick fix. Reference “A” in the photos above.
Once the power socket issue was corrected, I could see that I had 5 volts to the logic supply rails. The TEENSY derives it’s power from the USB socket (the “USB_VCC” net) but I added a high-side P-MOSFET (Si2305) and a simple “external power detection” to act as a “switch-over circuit”. The circuit supplies 5 volts from the TEENSY/USB connection to the rest of the components (via the Si2305) unless there is external power applied, at which time it breaks the TEENSY’s power connection to the rest of the components. The voltage difference between the USB power and the 5 volt regulator is only about 200 millivolts, so as long as the TTL levels are met then there should be no unforeseen issues using this method. However, I could see that with the TEENSY powered up, the USB power was not getting to the rest of the components. I knew I had run the circuit through LINEAR TECH’s free “LTspice IV” circuit simulator and it worked. After some investigation, I looked at the pinout of the Si2305 datasheet, the schematic symbol and the PCB layout symbol and saw that pins 2 and 3 were reversed on the schematic symbol. The Si2305 is one of two SMT devices on this PCB. The Si2305 is housed in a (3 pin) SOT-23 package. Luckily, pins 2 and 3 are on the same side of the component, so flipping the SOT-23 over, bending the pins back and resoldering them to the PCB solved that problem. The “switch-over circuit” was now functioning properly. It is difficult to see behind the TEENSY but reference “D” in the photos above.
With the power-supplies functioning correctly, I decided to check for proper communication with the TEENSY via the JTAG header. I am using the JTAG header because the ATMEL AT90USB1286 “on-chip debugger” can only be accessed via the JTAG interface, not the ISP interface. I much prefer to use the JTAG interface for on-chip debugging over the debug-wire interface because then JTAG interface is MUCH more reliable that the debug-wire interface. Sometimes the debug-wire interface can unexpectedly abort and will not reconnect, which leaves the AVR in a state that it cannot be communicated with unless the debug-wire fuse is disabled and the SPI interface is re-enabled and most times that requires an HVPP (or HVSP) connection to do so. However, newer versions of avrdude (6.0+) recognize this and temporarily sets the MCU into a state that the fuses can be re-programmed using the SPI connection.
Continuing, a simple query of the AT90USB1286 by avrdude yielded a “RSP_NO_TARGET_POWER” response. I checked pin 4 (VTRef) of the JTAG connector and it had no power. In looking at the PCB layout program, I could see there were traces between pins 4 and 7 (VSup) but not to Vcc. Well, that was the problem. Looking at the schematic, I could see that I had labeled those two pins as connecting to the “VDD” net but all the other components were connected to the “VCC” net. I had copied that particular component and it’s connections from another schematic and failed to rename the “VDD” net to “VCC”. Since some pre-made schematic symbols use the “VDD / VSS” nets for the power pin(s) and others use the “VCC / GND” nets for the power pin(s), I usually connect the “VDD / VCC” and “VSS / GND” nets together in my schematics. I failed to connect the “VDD” and “VCC” nets together in this schematic. Another simple fix as there was a VCC connection available on the neighboring 74HC14 at pin 14. Reference “E” in the photos above.
With JTAG power restored, I still was unable to communicate with the AT90USB1286 on the TEENSY module. After pondering about it for a few minutes, I considered the possibility that during the OEM’s programming of the PJRC “Half-Kay” boot-loader, perhaps the JTAG interface was disabled in the fuse programming. The only way to find out was to temporarily wire in an ISP connection and talk to the AT90USB1286 using the ISP interface. I had NEVER intended to use an ISP connection to the TEENSY because I wanted to use the on-chip debugger for code development, which is JTAG. In addition, the SPI connections are being used to communicate with the SD memory card and the 74HC299. The MISO connection from the SD memory card and the “QH” connection from 74HC299 are individually routed to the SPI port via a “pico-gate” MUX (NC7SP157, a single 74HC157-type MUX), which uses the “SS” (slave-select) signal from the SPI port to select between the two. It should, however, be easy enough to wire in the SPI connections to my AVR DRAGON but with the MUX driving the MISO signal, I’d have to connect to the SD memory card’s MISO pad to get through the MUX to the AT90USB1286. Well, I tried that and it still did not work. Then I realized that in SPI programming mode, the MISO/MOSI connections are reversed from that of the “normal” SPI operations as the AVR becomes the “slave”. The ONLY way to overcome this (hopefully) one-time operation was to cut the trace to the MISO pin at the TEENSY and reconnect it afterwards. A few minutes later and I had a successful ISP connection to the AT90USB1286 and yes, the JTAG interface was disabled. The only way to reset the fuses was to erase the AT90USB1286’s FLASH memory and thereby the “Half-kay” boot-loader. I had always intended to use Dean Camera’s(open-source) LUFA CDC boot-loader, so wiping out the (closed-source) “Half-Kay” boot-loader wasn’t a problem for me. A few minutes later and I had the JTAG interface working again and the cut trace restored. Reference “B” in the photos above.
BTW: Since there are 2 SMT components on the Z80 PCB and the NC7SP157 is housed in a 6-pin SC-70 package, it was easier to use my “home-brew” reflow oven to affix them to the PCB rather than breaking out my fine-tipped soldering iron. Using the larger tipped soldering iron would not have been a problem for the SOT-23 package but the for the SC-70 package, the pins are spaced too closely to even want to try.
With my initial issues overcome, it was time to start testing the hardware with the TEENSY. I’ll load AttoBASIC and use it to functional test each hardware block. Look for the results in the next entry.