Tony Duell wrote:
Sorry to barge
in, but I don't think is exactly correct. On most ARM
systems these days, for
example, there are multiple hardware breakpoints inside the jtag debug
logic which are
not intrusive. They don't perterb the instruction stream at all until
they are hit.
No, you misunderstood me. A breakpoint is intrusive in that when it is
hit it stps the code execution (There are plenty of other debugging
feautrs in some chip,s but they're not strictly breakpoints). For tyhe
sort of thing I would use a microcontroller for (which involves
generating precisely timed signals to control external hardware) I can't
have my progrma suddenly being stopped for the debugger.
A logic analyser will grabe state and not stop the program running.
I have a slightly different way of looking at the situation, but I
essentially agree with Tony.
About a decade ago, I was attempting to determine why the data from a
remote unit in the
field was causing problems. Ultimately, the difficulty was due to a
buffer overflow. Packets
of data were sent to a buffer as they were generated followed by sending
the data as soon
as the previous packet was confirmed received. When the end of the
buffer was reached,
the start of the buffer was used as the continuation. Normally, the
inflow of packets was
much slower than the outflow speed, so no problems would ever occur.
However, if an error was detected by the field unit, the error messages
to be sent
started to pile up. As Murphy's Law would dictate, the code to check
that the packet
to be overwritten by the inflow had been sent by the outflow was faulty,
so the
packets waiting to be sent were overwritten and corrupted.
Since there was np way to stop the iteration between the remote units
and the
master station at precisely the same microsecond, let alone dump the
contents
of the remote's memory (it was just a single board with a CPU, Memory, EPROM
and the minimum hardware to sense the field hardware), a logic analyser was
used to capture the data packets and their address pointers as they were
sent
to the buffer and then moved from the buffer and sent to the master.
Fortunately,
the logic analyser was PC based and saved the snapshot on a hard drive for
latter retrieval.
The snapshot consisted to what were considered to be the values of the
characters
in the data packet and their locations in the buffer for a selected
sequence of
instructions which were able to show that the input pointer for data
being stored
into the buffer had crawled over the top of the output pointer for data
being
removed from the buffer. In effect, the logic analyser stops a specific
sequence
of instructions which started at a specified instruction in the code and
froze the
stored data for the previous bunch (probably about 100) instructions so that
the data flow and buffer pointer values could be checked to be compatible.
After MANY, MANY, MANY, ..., ..., attempts over a few days, a snapshot
was found which identified the problem described above.
In effect, what the logic analyser did was to display the results of
stepping
through about 100 instructions showing the data values and address pointers
that were required as they were used by the program. This is exactly what
a debugging session would be when a used to actually stop the program and
then manually and visually inspects the values of interest. While the logic
analyser is much more restrictive, its great advantage is that it does NOT
change the timing of the operation since it captures any data it collects
in real time and stores it in its own buffers outside of and apart from the
system being tested without in any manner disturbing the system being
tested by that observation. The logic analyser can do this because it
is able to collect the data in its own buffer as the data is produced by the
test system without regard as to when the trigger location or event in the
system being tested will take place. When the event does occur, the logic
analyser then takes a simple action. It stops accepting any more data and
retains the snapshot of the previous bunch of instructions that preceded
the event. It is like asking the breakpoint to take place at a certain
location,
then asking the system to reverse itself and run backwards to look at what
HAD JUST HAPPENED during the previous 100 instructions. Obviously
impossible to do with a breakpoint on the normal way, but that is how the
logic analyser functions.
Please correct my memory of how the logic analyser functions if I did
not remember correctly - or if that is just one of the modes of operation.
To accomplish to feat, the logic analyser probably has to run at least
10 times
faster than the system being tested. (Tony, do you have any estimates?)
With the fastest CPUs being used today, that is becoming increasingly MUCH
more difficult. Tony, is that what you are concerned about as well, how the
logic analysers are able to keep up?
Jerome Fine
