New Build: Garbled Serial (Scope Captures Included)

[Danny S]

Throwing myself on the mercy of the court here. I'm learning so much in troubleshooting, which is the goal of my project, but now I'd like to get to the next step (a working computer).

I built my RC2014 (full monty) a few months ago and have not seen it boot once. We've been through some tough times this summer, and I have attempted to correct some errors I made early on (specifically replacing a damaged DIP socket for an inverter IC).

Symptoms / observations:

 - Serial I/O is complete garbage: mostly random characters coming through the terminal (115200, 8N1 via an FTDI 5V adapter). Sometimes I can get a reaction by typing keys or pressing spacebar/return. Most of the time the line is just dead.

 - Gone over all solder joints and checked for shorts and other errors. Visual inspection is fine as far as I can tell.

 - Clock appears to be healthy and square-ish.

 - Data and address lines show what I assume to be normal activity

 - Tx and Rx lines are almost always high (5V)

 - Tx/Rx activity does not match Spencer's reference (again, both lines are high from the moment RESET goes high, and they tend to stay that way).

My thinking right now, is maybe something is wrong with my FTDI cable: measuring TXD or RXD (when completely disconnected from the RC), I get +5V at all times.

Now, before I post my measurements, I'd like to note that I'm unclear about whether Tx/Rx are supposed to be high when idle. My understanding is that in RS232, the lines should have a positive voltage at rest, but in TTL they should be 0V. However, the RC troubleshooting documentation shows both at 5V and dropping when there is activity.

Thanks for any guidance you guys can offer. I'm close to ordering another RC kit for comparison, but I'd rather spend that money on add-ons instead of duplicate parts.

I'm still learning how to use my USB oscilloscope so if there is anything I should be doing to get better readings, I'm open to suggestions. I'm not sure my  scope is sensitive enough to capture the Tx activity after a reset. It seems to be limited to 1M samples, and doesn't auto trigger so capturing the signals after a reset is a matter of timing and luck.

Here is my clock:

And here are the CLOCK (channel 0), Tx, Rx (channel 1, 2), and D0-D5:

Here is CLOCK, Tx, Rx, and A0-A5:

Here are the first 2 seconds (at 500KSa/s) after a reset (showing CLOCK, Tx, Rx, with RESET on channel 3):

Here is an example of what I see in Tera Term:

[Steve Cousins]

Hi Danny

Here are my observations.

"And here are the CLOCK (channel 0), Tx, Rx (channel 1, 2), and D0-D5:"

Channel 1 (TX) looks like a simple square wave. The period is too long for 115k baud. This is not a sensible serial signal.

"Here is CLOCK, Tx, Rx, and A0-A5:"

The address lines seem to be showing a simple binary count, like it is just seeing NOP instructions at every address. It is just stepping through memory and not following any normal program flow. The period of A0 is consistent with it repeatedly reading and processing a simple instruction like a NOP.

As a guess I'd say perhaps the ROM chip is not being enabled, so the processor is not seeing meaningful instructions. It would be seeing and executing whatever the default data bus levels happen to be.

Might be worth trying to capture ROM CE, RD, WR, MREQ, A0, A1, A2 A3

This would give a good indication of what the processor is doing.

Another thought: perhaps that binary count of the address bus is just memory refresh cycles. I think it would probably look something like that if memory refresh is running normally but the processor is somehow not running a program.

I can't think how the serial transmit could output the square wave shown.

Steve

[Mark T]

It might be worth trying a simple loopback test on your FTDI. Disconnect from RC2014, Connect Tx to Rx, disable flow control in teraterm and then if you type characters into teraterm you should get them echoed back to the display.

While doing this you could also check with your scope to see the tx/rx activity.

There have been a few reported problems with the serial resistors to the ftdi on the serial card, dependent on the ftdi supplier. Yours is probably a recent kit and has the lower values already.

Mark

[Danny S]

Hi Steve, thank you for your quick and thoughtful response. I've captured the lines you suggested (hopefully at a meaningful frequency). Any further advice you have is appreciated!

I think the serial square wave was simply the line being high for a period of time, then dropping low. It's possible my probe dropped off the board and I didn't notice it (note in my other captures the Tx line is always high).

This is:

CLOCK

ROM CE

RO (I assume you meant RO, but please let me know if there is such a thing as RD that I missed)

WR

MREQ

A0 through A3

[Steve Cousins]

Hi Danny

I did mean RD. That's the name of the READ signal on the processor, but my Pro Backplane labels it RO, so I guess you have the signal I was wanting to see. 

Those traces are confusing.

The clock signal appears to be less than 1MHz, yet your scope identified it as 7.3 MHz.

Also the RO (RD) signal is changing more rapidly than the clock signal. This should not happen.

Similarly there are faster changes on the address lines, which shouldn't happen.

I think perhaps your sampling rate or sampling timing is such that it is not showing what is really going on with the clock. 

Until you can get a set of traces where the clock looks correct and the relationship between the clock and the other signals is consistent with those shown in the Z80 data, it is difficult to say what is going on.

What ROM are you running?

With such detailed traces (once you get ones that are telling the truth) it should be possible to follow the first few instructions of the ROM to see if it is running correctly. Thus the question about the ROM.

Once you get the first 25us or so of traces which look correct, the above set will be enough to check if it is running the ROM code correctly for those few microsecond.

So try a faster sample rate. About 10 times faster if possible.

Steve

[Mark T]

RO is a typo in the silkscreen, it should be RD.

Clock looks slow but you mentioned your scope is 1Ms/s so possibly just aliasing.

Address lines appear to show a tight polling loop, as would be expected if it was checking for TX ready or RX ready.

[Danny S]

Great idea Mark! I had done a loopback test earlier, and that's fine (text is echoed in Tera Term as expected).

But I didn't think to compare the signal levels. I just did and confirmed the loopback Tx/Rx idle state is indeed +5V. Here's what it looks like when I type a string of characters with Tx/Rx jumpered, with clear swings from 5V to 0V:

Now with the RC2014 connected, and the scope on Tx (pin 35), I just see a solid +5V, which I assume is an idle line. But there is something odd: it's a really "noisy" +5V, and it quiets a bit if I hold RESET.

Here it is before and after holding RESET (blue line is when I hold the button):

And here's what Tx, pin 35, looks like when I hold down a key on the keyboard:

It's not dropping to 0V as with the loopback test. Do you think that might be abnormal? Or is it just picking up noise from the Rx line coming in? It never, ever shows 0 volts, so it's either not transmitting anything (even right after a reset), or it's being held at 5V against its will.

Probing the Rx line (pin 4 on the serial module), I see clear swings high/low for incoming data:

And Rx (pin 36) on the backplane:

Thanks for shedding some light on the serial link!

[Danny S]

I might be at the limits of this USB scope (a Hantek 6022BL), or at least the limits of the software, or my knowledge of how to use it. No, the clock is not captured clearly at anything but the fastest rate. I can capture 1M at 16MSa/s, or 1K at 48MSa/s. Here are both!

Again, thank you for your input and guidance.

[Stuart gmail]

When I built my RC2014, I followed some photos for the wrong rev memory board and therefore didn’t have the page link from RAM to ROM board. What I found when I looked at the data lines on the processor with the oscilloscope was that sometimes the data lines were a solid 1 and others a solid 0, but I had a whole lot in intermediate levels where both the ROM and ROM board were trying to drive the data bus in different directions leaving the bus at around 2.5 v. Unfortunately the logic analyser is unlikely to show these levels. It most likely will represent it as a 1 or a 0 and convince you that the levels are ok.

Admittedly my oscilloscope is a 60MHz one that copes very well with the 7MHz Max signals on the bus.

 

 

From: rc201...@googlegroups.com <rc201...@googlegroups.com> On Behalf Of Danny S
Sent: Saturday, 25 August 2018 10:03
To: RC2014-Z80 <rc201...@googlegroups.com>
Subject: [rc2014-z80] Re: New Build: Garbled Serial (Scope Captures Included)

 

I might be at the limits of this USB scope (a Hantek 6022BL), or at least the limits of the software, or my knowledge of how tonal use it. No, the clock is not captured clearly at anything but the fastest rate. I can capture 1M at 16MSa/s, or 1K at 48MSa/s. Here are both!

 

 

 

Again, thank you for your input and guidance.

On Friday, August 24, 2018 at 4:28:09 PM UTC-7, Steve Cousins wrote:

 

 

Until you can get a set of traces where the clock looks correct and the relationship between the clock and the other signals is consistent with those shown in the Z80 data, it is difficult to say what is going on.

 

What ROM are you running?

With such detailed traces (once you get ones that are telling the truth) it should be possible to follow the first few instructions of the ROM to see if it is running correctly. Thus the question about the ROM.

 

Once you get the first 25us or so of traces which look correct, the above set will be enough to check if it is running the ROM code correctly for those few microsecond.

 

So try a faster sample rate. About 10 times faster if possible.

 

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/7eb2da2b-25d9-4e6c-acea-5ff8490304fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark T]

Channel 4 doesn't look correct to me for MREQ. Maybe as Stuart suggested using a logic analyser function is not going to show incorrect levels caused by two lines shorted. Channel 4 looks like a combination of MREQ and RFSH.

What does MREQ look like on a scope trace?

Mark

[Stuart Smith]

Unfortunately I cant help with scope traces as I am sitting in a coronary care ward seperated from my rc2014.

I would expect to see it transition low pretty much once every 4 clock cycles,  except when there is an I/O command. 

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/1878e954-d974-48a8-9e79-e5c79a3cfb5b%40googlegroups.com.

[Mark T]

I don't have a scope, but for each instruction fetch I'd expect MREQ to be low for about 1.5 clock cycles, followed by high for about 2 clock cycles for the refresh cycle. There are a few periods of MREQ high for two or three cycles, but there seems to be too many RD operations between those for them to be the instruction fetch cycles.

Looking at MREQ with a scope instead of logic analyser might show whats happening.

It also might help to look at RD, MREQ, M1, RFSH.

Mark

[Steve Cousins]

Hi Danny

Looks a pretty healthy system to me.

Mark is right that it is sitting in a tight loop reading from the serial chip.

Here is part of your second capture:

The red box shows a single cycle of what appears to be repeating code executions.

Green lines are reads from the ROM.

Blue lines are reads from I/O.

The traces are:

Clock

ROM chip enable (active low)

Read (/RD)

Write (/WR)

Memory request (/MREQ)

A0 to A3

Starting at the first green line after the red frame, we have the following sequence...

Green: Read from ROM at address xxx0

Green: Read from ROM at address xxx1

Blue: Read from I/O address x0

Green: Read from ROM at address xxx2

Green: Read from ROM at address xxx3

Green: Read from ROM at address xxx4

Green: Read from ROM at address xxx5

Green: Read from ROM at address xxx4

Green: Read from ROM at address xxx5

We only have the lowest 4 bits of of the address, which is shown above in hex with an 'x' representing an unknown digit.

I think this sequence is:

Instruction to read from I/O address, probably IN A,(80), which is a read from the serial chip.

Green: Read from ROM at address xxx0

Green: Read from ROM at address xxx1

The I/O read as instructed above.

Blue: Read from I/O address x0

Instruction(s) to test if a data byte has been received by the serial chip

Followed by a loop back to the beginning of the sequence if no data byte available.

Green: Read from ROM at address xxx2

Green: Read from ROM at address xxx3

Green: Read from ROM at address xxx4

Green: Read from ROM at address xxx5

Green: Read from ROM at address xxx4

Green: Read from ROM at address xxx5

Without knowing exactly which ROM you have and you hardware configuration it is not possible to tell if this analysis is correct, but it looks a safe bet it is waiting for a serial byte to be received.

This does not prove your RAM is working, but it probably is for the ROM code to get as far as reading the serial chip.

Also it does not prove that all of the ROM is being read correctly. ie. it does not prove all of the address lines are ok.

Seems pretty safe bet all the data lines are ok. Similarly the main control lines are probably ok.

The most likely cause of it being stuck here is that it never receives a serial byte. If you can confirm a byte arrives at the serial chip in good shape by monitoring the serial chip's receive input, then I think the problem is likely on the serial module. Perhaps one of the serial chip's data or control signals is missing or stuck. Perhaps one of the clock signals to the serial chip is missing or stuck.

I'm puzzled by the first traces you posted appeared to show a processor just 'counting' on the address bus and the serial TX line having a square wave on it. In other words a very broken system. Yet the latest traces look like a pretty good system, waiting on a serial receive, like it is supposed to.

Steve

[Mark T]

Steve,

Do you think the MREQ timing looks correct? Maybe its just the sample capture rate on clock and MREQ that was confusing the cycles, but I expected to see the MREQ going high betwen each address change and not just for the IO instructions.

Mark

[Steve Cousins]

Hi Mark

/MREQ looks ok to me. I've highlighted /MREQ in the illustration below.

Z80 data sheet clearly shows /MREQ should indeed go high at the end of the read pulses etc, which it does. Admittedly it is for a very brief time, but seems consistent with the data sheet.

Steve

The traces are:

Clock

ROM chip enable (active low)

Read (/RD)

Write (/WR)

Memory request (/MREQ)

A0 to A3

[Danny S]

I just wanted to thank everybody for their input so far. I'm going to see if I can collect some data from the serial module and lines. I'm also going to see if I can find a better software package for the scope.

Danny

[Danny S]

My ROM is the standard ROM included in the full monty kit.

https://www.tindie.com/products/Semachthemonkey/rom-module-for-rc2014-z80-homebrew-computer/

I'm not looking at it right now, but I believe the sticker on it has a series of 0's and a 9 at the end (something like R0000009).

. 

[Mark T]

You should still check the links on the ROM module to make sure you are selecting the correct ROM bank. If for example you were selecting a ROM bank for the SIO board, but your system has the 6850 serial board, you would probably still see the software running the polling loop but never seeing the ready condition.

Chip enables on the serial board should also confirm the rom is addressing the correct serial module type.

Mark

[Steve Cousins]

Hi Danny

Thanks for the ROM info.

That ROM contains BASIC and also the small computer monitor.

Have you tried both programs?

Just to clarify you select the required program with jumpers. All zero runs BASIC, all ones runs SCMonitor, I think (not checked).

These programs work differently and it may provide more clues trying both.

Steve

[Danny S]

Just wanted to follow up as a courtesy and say thanks again for the insight. I tried setting the ROM selection to all 1's and did not see much difference. There was still activity on the bus but no serial output (none at all, not even garbage).

I started using Sigrok, another logic analyzer, and discovered that the serial enable line was not responding to IOREQ (based on my examination of the circuit it seems the serial enable should be low anytime IOREQ is high. Anyway, I swapped out the 74HCT on the serial module and that seemed to solve that, but still nothing useful on the serial I/O.

Pretty sure I am just going to get another kit, and test the modules one by one (starting with the serial module).

Here are some captures, in case anything jumps out at your experienced eyes.

Immediately after reset with BASIC selected:

Immediately after reset with SCM selected (noticing the lack of activity on ROM CE, I think maybe the probe was not attached for this run):

At this point I began measuring the serial enable line and discovered it wasn't doing anything. The rest of the captures are after replacing the HCT74.

All captures below are immediately after a reset.

Sigrok has a Z80 instruction interpreter, so I ran that. I don't understand it but thought I would include it.

[Mark T]

Hi Danny,

What was the full warning message in the last plot, only shows "Prefix not fol" ?

Mark

[djrm]

The Sigrok trace looks all wrong, I would not pay any heed to it. I'm not sure exatly what it should look like but I suspect the capture is not fast enough or it has too little resolution. If your capture device is maxed out then you could try capturing fewer lines. Try and find an example to compare it with. hth David.

[Danny S]

Thanks - looking at them now, it's kind of obvious that lines shouldn't be changing state multiple times in a clock cycle. Unfortunately that's as good as it gets with my scope.

[Danny S]

An incredibly generous member was kind enough to offer me some known-good modules to test with, so I'll have this sorted soon enough.

However, meanwhile, I went back and measured the pins on the backplane with my oscilloscope (since we have established that the logic analyzer is junk).

I found one line that was suspect - A14 is always hanging around +2V to +4V. And that's how I learned the difference between 74HCT04 and 74HCT32 chips.

So I swapped in correct component, and made some progress. No more suspicious voltage, but still garbage on the serial line. However, it is now very consistent garbage:

Everytime I press RESET, I get a nice stream of pseudo-text.

Maybe it's just coincidence, but I see parts of the words "list", "print", "load" and "save". Why they are repeating 4 times after reset, I guess I don't know. 

I'll let you know when I've identified the culprit!

[Alan Cox]

I think you are for some reason seeing a chunk of the ROM being output. The keywords are stored with the high bit of the next byte set. That's being translated by your terminal into a chinese character also eating the first by of the next one I think - hence PRINT LIST CLEAR LOAD SAVE etc....

So it's executing valid code to output stuff by the look of it but it's outputting crap. Looks like your CPU is good, your I/O is good, your data is good but perhaps a high address bit is misbehaving ?

[Mark T]

Take a look at the schematic where you had the wrong chip fitted. From the pinout of the wrong chip you can see where it has outputs that were conflicting with the outputs of other chips. Its possible that two outputs connected together could have damaged one of the chips that is still fitted in your system.

As Alan says, possibly a high address line is faulty. Unfortunately that might mean the z80 address line output has been damaged.

Mark

[Danny S]

It was the CPU!

Just thought I'd wrap this one up. A forum member sent me some spare components and it turns out the serial board was fine, ROM was fine, RAM was marginal (unstable but not the cause of the garbled serial output).

Simply placing my Z80 into another module solved the issue.

I am unable to determine the problem with my original Z80 board. I've tested continuity on all the pins and resoldered everything just to be sure. It's such a simple board, so I don't know what could be so wrong with it!

Either way, thank you everyone for your input as it certainly taught me a lot about the system and troubleshooting. And, of course, the value of having known-good parts.