COBHAM GRMON3, Руководство пользователя, Страница: 37 / 239

GRMON3-UM
June 2019, Version 3.1.0
37 www.cobham.com/gaisler
3.12. Automated operation
GRMON can be used to perform automated non-interactive tasks. Some examples are:
• Test suite execution and checking
• Stand-alone memory test with scripted access patterns
• Generate SpaceWire or Ethernet traffic
• Peripheral register access during hardware bring-up without involving a CPU
• Evaluate how a large set of compiler option permutations affect application performance
3.12.1. Tcl commanding during CPU execution
In many situations it is necessary to execute GRMON Tcl commands at the same time as the processor is executing.
For example to monitor a specific register or a memory region of interest. Another use case is to change system
state independent of the processor, such as error injection.
When the target executes, the GRMON terminal is assigned to the target system console and is thus not available
for GRMON shell input. Furthermore, commands such as run and cont return to the user first when execution has
completed, which could be never for a non-behaving program.
Three different methods for executing Tcl commands during target execution are described below:
• Spawn one or more user Tcl shells. The user shells run in their own thread independent of the shell controlling
CPU execution. This is done with the usrsh command.
• Detach GRMON from the target. This means that the application continues running with GRMON no longer
having control over the execution. This is done with the detach and attach commands.
3.12.2. Communication channel between target and monitor
A communication channel between GRMON and the target can be created by sharing memory. Use cases include
when a target produces log or trace data in memory at run-time which is continuously consumed by GRMON
reading out the the data over the debug link. For this to work safely without the need to stop execution, some
arbitration over the data has to be implemented, such as a wait-free software FIFO.
As an example, the target processors could produce log entries into dedicated memory buffers which are monitored
by an exec hook. When new data is available for the consumer, the exec hook schedules an asynchronous bus read
with amem to fetch all new data. When the asynchronous bus read has finished, the exec hook acknowledges that
the data has been consumed so that the buffer can be reused for more produce data. One benefit of using amem is
that multiple buffers can be defined and fetched simultaneously independent of each other.
3.12.3. Test suite driver
GRMON can be used with a driver script for automatic execution of a test suite consisting of self-checking LEON
applications. For this purpose a script is created which contains multiple load and run commands followed by
system state checking at end of each target execution. State checking could by implemented by checking an appli-
cation return value in a CPU register using the reg command. In case an anomaly is detected by the driver script,
the system state is dumped with commands such as reg, bt, inst and ahb for later inspection. All command output
is written to a log file specified with the GRMON command line option
-log
. It is also useful to implement a
time-out mechanism in an exec hook to mitigate against non-terminating applications.
The example below shows a simple test suite driver which uses some of the techniques described in this section
to test the applications named
test000.elf
,
test001.elf
and
test002.elf
. It can be run by issuing
$ grmon <debuglink> -u -c testsuite.tcl -log testsuite.log
$ grep FAIL testsuite.log
in the host OS shell. Target state will be dumped in the log file
testsuite.log
for each test case which returns
nonzero or crashes.
Example 3.1. Test suite driver example
# This is testsuite.tcl
set nfail 0