> On Mar 26, 2021, at 5:08 AM, Rob Jarratt via cctalk <[email protected]>
> 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
