26 Mar
2021
26 Mar
'21
6:23 a.m.
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