Logic Analyser Usage Advice

[Paul Koning]

> On Mar 26, 2021, at 5:08 AM, Rob Jarratt via cctalk <cctalk at classiccmp.org> wrote:
> 
> I have an old HP 1630G logic analyser. I am trying to use it to debug a
> problem with an 82C206 peripheral controller (or rather I think damage
> between the CPU and the peripheral controller). I am not very experienced
> with logic analysers and I wonder if I am using it correctly.
> 
> What I am trying to do is see which internal registers are being
> read/written and the values. To do this there are two signals (XIOR and
> XIOW) that trigger the read/write on their rising edge. So I have connected
> the XIOR and XIOW signals to the J and K clock inputs and set the LA to
> clock on the rising edge. I have then told the LA to trigger on a particular
> address range (in the State Trace screen if anyone is familiar with this
> LA).
> 
> When I run the analyser it complains of a slow clock. This makes sense,
> because I am using the read/write signals to drive the clock inputs so that
> I only capture actual reads and writes to the peripheral controller.
> However, I don't seem to be getting sensible values in the trace and I am
> wondering if the LA is really not capturing anything because of the slow
> clock?
> 
> I don't think it makes sense to clock the LA on the actual clock signal
> because I won't be able to capture the address and data values on the rising
> edge of the read/write signals and I would end up with traces full of
> useless data.

If you have the trigger set to the event you want that wouldn't be a problem; the LA would not store anything until the trigger hits.

I have a different ancient logic analyzer, a Philips/Fluke model.  It has "state plus timing" capture, meaning that it can capture sequences of clocked state changes, time-labeled waveforms, or both simultaneously.  What you're doing corresponds to "state" capture, which uses a clock.

If you're capturing with a clock that means the LA captures the inputs at each specified clock edge -- in your case, rising edge of either of those two signals.  (Does it really have two clocks and defines that it captures on a clock event from either of them?)  That would mean you see ONLY the points in time when that edge occurs.

If you have a bus transaction that begins with a rising XIOR or XIOW, and then some other things happen -- like an address or data transfer perhaps accompanied by some control signal -- then what you're doing won't work because you won't be capturing those later points in time, since they don't occur at an XIOR/W edge.  What you need instead is either to specify a constantly running bus clock as your clock, or capture in timing mode (every N nanoseconds) if the LA has such a mode.  You would then specify a trigger along the lines of: wait for edge on XIOR or XIOW, then look for address in the range x to y.  If the address is on the bus at that edge this is easy: "(rising XIOR or rising XIOW) and (addr >= x and addr <= y)".  If the address occurs later, you'd have to specify something along the lines of "edge then address match within z nanoseconds" to describe an address match occurring within that same bus cycle.  Or if the address is accompanied by an address strobe it would be "edge then within z nanoseconds (address strobe and address in range)".  Depending on your LA trigger machinery you may be pushing the limits of what it can do.  If all else fails you might need to concoct some external circuit to implement part of the trigger condition, and hook the output from that helper circuit to another LA pin as one of the trigger terms.

	paul