An Improved MENSCH™ Microcomputer

[Martin_H]

I removed the 0.1uF caps and tested the board without C5 and C6. It was extremely difficult to get a clean reset. So decoupling caps are definitely needed.

I cleaned the PCB and reinstalled 10 nF caps for C5 and C6. The reliability was the best of the three capacitance values (0.1 uF, 10 nF, and none). I will stick with 10 nF for C5 and C6 matching the WDC w65c265qbx values. The upside of this test is I'm getting really good at SMD rework.

Hypothesis: The power and ground lines for the w65c265 all come from a single pair from the left side of the board which run under the chip and provide power to the four pairs of power pins (see attached image). I'm wondering if during reset power demands are high enough to intermittently cause ground bounce.

Test: Run independent ground wires to the C5, C6, and C7 decoupling caps.

If this fixes the problem, I will accept BDD's chastisement for not doing a four-layer board.
If it doesn't fix the problem I will build the second board to see if the problem is reproducible.

[Martin_H]

I ran independent ground wires to the C5, C6, and C7 decoupling caps, re-tested, and got interesting behavior.

Good news: When it worked, I was able to run off power from the USB port. That didn't work previously, so it's a minor improvement.

Bad news: The reset behavior was significantly worse, and in a big way. This isn't a fix and made it worse.

Conclusion: Working USB power makes me wonder if it still might be a ground bounce issue.

Epilogue: Since it wasn't a fix, I removed the ground wires and unfortunately damaged the C5 ground pad. I had to resolder the decoupling cap directly to the trace by turning it slightly cattywampus. It works but isn't pretty, so much from my improved SMD rework skills.

[SamCoVT]

Martin_H wrote:

... unfortunately damaged the C5 ground pad. I had to resolder the decoupling cap directly to the trace by turning it slightly cattywampus. It works but isn't pretty, so much from my improved SMD rework skills.

Soldering SMD components to damaged/comprimised PCBs to restore functionality is advanced SMD rework. You might have missed the fact that you've already made it to the next level. When playing with the "hobby" setting turned on, most of the points in this round come from restoring functionality with only a few points for how it looks in the end.

[Martin_H]

@SamCoVT, thanks for the pep talk.

@All, Interesting progress.

As I said previously, if grounding didn't resolve the issue, I would build a second board to see if the problem was reproducible. While I was at it, I swapped the C2 and C4 capacitors on the 3.6864 MHz oscillator to match the datasheet, rather than the w65c265qbx schematic. The result was a board that didn't work at all. I connected PHI2 to the scope and always got the stuck oscillation. I swapped the C2 and C4 capacitors to 27pf and 47pf respectively, and both boards behaved identically.

While I was at it, I experimented with using CSB3, CSB5, CSB6, and CSB7 to control RAM address decoding. CSB3, CSB6, CSB7 behave exactly as advertised in the datasheet with RAM in the expected address space. CSB5 didn't work as advertised. Only the on-chip RAM was present in bank zero, but the 128k RAM was present in bank 1 and bank 2.

Conclusions:
* Soldering the QFP100 was super easy and barely an inconvenience the second time around. Okay, a slight overstatement as there were a few bridged pins, but it just didn't seem that hard this time.

* The datasheet is correct about the oscillator resistance values for R3 and R4, but the schematic is correct (or at least more correct) about the capacitance values for C2 and C4. I have no idea how anyone could design a working PCB using the datasheet without trial and error.

* I am back to thinking the root cause is a problem with the oscillator, and perhaps the capacitance values for C2 and C4 aren't quite correct. Perhaps replacing C2 and C4 with lower values would make the oscillator is more stable. But then I'm in disagreement with both the datasheet and schematic.

* If I build a revision 2 of this PCB, I am switching to a TTL can oscillator as this crystal oscillator stuff is for the birds.

* Either I'm missing something in my understanding of CSB5, or the datasheet is wrong. But I saw what I saw. I retested several times because the result was so unexpected.

[barnacle]

Just a thought: is it possible that the oscillator is still unstable when the reset signal is deasserted? You'd need a scope with single-shot operation, triggered on the rising edge of ~reset, to see anything.

Neil

[Martin_H]

barnacle wrote:

Just a thought: is it possible that the oscillator is still unstable when the reset signal is deasserted? You'd need a scope with single-shot operation, triggered on the rising edge of ~reset, to see anything.

Neil

A race condition like this could explain the intermittent nature of the problem. The normal sequence of events I have seen is that as long as reset it depressed, both the oscillator and phi2 remain low. After the DS1813 lets reset go high, the oscillator starts, and phi2 follows. This makes sense because the oscillator drives phi2. But occasionally I see a delay in the oscillator and phi2 remains unstable. I have also seen the oscillator be unstable and then lock into regular oscillations. If I can see it, it's also happening at speeds I can't see. Clicking reset again results in normal operation.

My scope has something called single sweep mode for non-repeating signals that might work. But I haven't used it, and it will take some time to figure out how to use it. But if this is the case, I'm not sure how to fix it other than make the oscillator more stable.

Given that adding ground lines to the decoupling capacitors made the problem worse. I was curious what would happen if I added an additional ground line to one of the oscillator's loading capacitors. I chose C4 since it has the longest trace to ground and the highest value of 47 pf. The result was the oscillator was completely unstable.

This was probably not the best test as adding a ground wire might increase parasitic capacitance and inductance of C4, and I already know how twitchy that oscillator is. But this time I used ultrafine wire to avoid any chance of damaging the grounding pad by pushing or pulling on the wire with the tweezers.

[barnacle]

That seems an odd design choice from WDC: to make an oscillator which is disabled by the processor status (if that is indeed the case).

I might consider version two which has a completely independent oscillator (say, a 4-pin module) that oscles all the time it's powered. If the oscillator doesn't (can't!) start before the processor comes out of reset, there's very little chance of it being stable in the first cycle or two.

IIRC you had a standalone oscillator circuit that you were using to test your crystals: try using that?

Neil

[Martin_H]

I just found this in the WDC documentation it explains some of what I've seen.

Code: Select all

Clocks
The W65C265S has two clock inputs, called CLK (the default clock) and FCLK (a separate fast clock).  On reset, the W65C265S uses the CLK oscillator to run the W65C816S core processor.

The second oscillator, FCLK, is under program control.  Software has the option to turn it on or off, and to select it as the input clock for the W65C816S.  On reset, this oscillator is turned off.

The ROM monitor assumes that the CLK oscillator is 32768 Hz, and uses it to identify one of the five acceptable frequencies of FCLK.  The CLK oscillator is also used to maintain the time-of-day clock.

This explains why FCLK is off during reset. To test this, I hooked CLK to the scope and measured it against the signal generator. It is running stable all the time and is independent of reset at the desired frequency. This also explains why I was seeing the slow PHI2 setting when the FCLK oscillator wasn't working. The system was defaulting to the slow CLK oscillator. Two weird events understood.

What's not understood is why this transition sometimes doesn't happen and PHI2 gets wonky. This also means the ROM monitor has no excuse for the time-of-day clock running fast, because the slow clock is still available.

[plasmo]

Does your CLK (32khz) ran fast? 32khz clock is very low power and sensitive to noise pickup, so there is an exclusive zone around the clock logic to shield from noise. Have you trace out the clock logic to make sure there are no fast signals running next to it?
Bill

[Martin_H]

plasmo wrote:

Does your CLK (32khz) ran fast? 32khz clock is very low power and sensitive to noise pickup, so there is an exclusive zone around the clock logic to shield from noise. Have you trace out the clock logic to make sure there are no fast signals running next to it?
Bill

It's running at the correct frequency. I was able to use my scope and signal generator to ensure that. But there are two signal lines close to it. RESB runs under it and PHI2 runs above it. RESB isn't a high frequency signal, but it does transition from low to high during the time this is a problem.

[barnacle]

But the same problem arises: is the slow clock running stably when reset is raised? Low frequency low power clocks can take a long time before they're running to spec (you might see a slowly increasing sine wave signal on the clock input (and possibly output) as things start to work). Reducing R5 might help things?

I'm assuming that you're trying to run the default boot loader/monitor software, so hopefully WDC have got things sorted out there and activated the switch to the fast clock.

Neil

[SamCoVT]

I'm looking at the ground used for C1 and C3, the caps on your 32kHz crystal. In order to connect to the ground that the processor is using, is it true that the trace goes down towards the south edge of the board and then all the way east to that corner, then all the way north to that corner (where it meets up with the power supply connector), then all the way west to that corner, and then finally halfway south before it comes over to the processor?

The ground used for the crystal caps should be a very short connection to the ground used by the IC driving the crystal. You may just want to add a little jumper from the ground on C1 over to the ground on C7 to make a direct connection there. If that helps, then you may want to cut the trace leaving C3, as that ground is carrying current from other ICs like U5, the 7400. Your other crystal might benefit from the same treatment.

PCB layout tracing ground path

[Martin_H]

Thanks for the feedback and ideas.

Software success first. I have setup a tool chain using make, ca65, ld65, and srec_cat to produce s record files. I then use TeraTerm's send file function to load the s records into RAM, hit reset, and use the monitor's J command to execute. Having to hit reset to terminate the s record load is likely because I'm missing a termination record. But I don't understand s record well enough yet.

SamCoVT wrote:

I'm looking at the ground used for C1 and C3, the caps on your 32kHz crystal. In order to connect to the ground that the processor is using, is it true that the trace goes down towards the south edge of the board and then all the way east to that corner, then all the way north to that corner (where it meets up with the power supply connector), then all the way west to that corner, and then finally halfway south before it comes over to the processor?

The ground used for the crystal caps should be a very short connection to the ground used by the IC driving the crystal. You may just want to add a little jumper from the ground on C1 over to the ground on C7 to make a direct connection there. If that helps, then you may want to cut the trace leaving C3, as that ground is carrying current from other ICs like U5, the 7400. Your other crystal might benefit from the same treatment.

Your description of how the ground reaches the loading caps and processor is correct. How that could cause oscillator instability also makes sense. I will try a wire from C1 to C7 to see what happens.

BTW This is interesting because in a previous test I ran additional ground wires for the processor decoupling caps which made the problem worse. That hints at some sort of grounding issue, but perhaps I tried the wrong solution.

barnacle wrote:

But the same problem arises: is the slow clock running stably when reset is raised? Low frequency low power clocks can take a long time before they're running to spec (you might see a slowly increasing sine wave signal on the clock input (and possibly output) as things start to work). Reducing R5 might help things?

I'm assuming that you're trying to run the default boot loader/monitor software, so hopefully WDC have got things sorted out there and activated the switch to the fast clock.

Neil

I'm using the default boot load/monitor.

Once the slow clock is running it is independent of reset.

If all IC's are on the board and power is supplied from the DC jack. It works most of the time. When it doesn't the slow clock either doesn't start or looks unstable.

If all IC's are on the board and power is supplied by USB. It doesn't work at all, and the slow clock either doesn't start or is unstable.

If the only IC on the board is the W65C265 and power is supplied by USB. It works intermittently. But when it doesn't the slow clock either doesn't start or is unstable.

Interesting data point. When using USB power, the ground comes from the FTDI jack and travels around the board counterclockwise. That creates a situation where the distance from the loading cap ground to processor ground is greatest.

[Martin_H]

Fantastic news. SamCoVT your diagnosis was correct.

I ran a small jumper from C1 ground to C7 ground. I went for gold and connected USB power with all chips in their sockets. The Mench monitor displayed the boot prompt. I hit reset 30 times and there were no reset problems. That never worked at all in previous tests and now I have seen no failures.

I am also able to run the board off battery power with all chips installed and it works that way as well.

I will correct the PCB layout to match and upload to GitHub shortly. I'm on the fence about making the minimal change or altering the trace for the FCLK caps as well.

Update: I made the minimal changed to the PCB layout, regenerated the Gerbers, checked in, and pushed to GitHub. Anyone who wants to build one of these should be able to use this design without the headache I went through.

@All, thanks for your help with this project. I now consider it a complete success and will move onto the software phase.

[Martin_H]

I have written several sample programs and uploaded them to RAM. I can also write to the EEPROM. But I'm having a problem with the 65c22 that straddles the line between software and hardware, and I'm not sure which it is.

The symptom: When I read or write to the address that the 65c22 should be memory mapped to. I get junk. When I write $00 or $ff to it, I don't get those values back. Basically, there doesn't appear to be anything at that address space.

My first thought was that I messed up the bus connections. So, I looked at the 65c22's pinout and validated the data and address lines. I then verified the phi2 was correct and that WEB was connected to the RWB pin. I also compared it to other 6502 SBC schematics that I know work and the WDC Mench computer schematic. It all looks reasonable.

That seems to leave address decoding logic. My design follows the WDC design for their Mench computer which uses this address decoding:

Code: Select all

w65c265    65c22
CSB1    -> CS2B
A5      -> CS1. 

If I understand both datasheets correctly, this should memory map the 65c22 in the CSB1 address space ($dfc0) offset by A5 when its high ($10). Which should be VIA base of $dfd0 ($dfc0 + $10). Does this make sense?

Indeed, when I write or read to $dfd0 my logic analyzer sees CSB1 pulse low. A5 is pulsing all the time so it's hard to know if it's high when CSB1 is low, but it should be high for address $dfd0.

I could be missing something basic about 65c22 interfacing, so any thoughts would be helpful.