GRMON3-UM
June 2019, Version 3.1.0
15
www.cobham.com/gaisler
grmon3> load v8/stanford.exe
40000000 .text 54.8kB / 54.8kB [===============>] 100%
4000DB30 .data 2.9kB / 2.9kB [===============>] 100%
Total size: 57.66kB (786.00kbit/s)
Entry point 0x40000000
Image /home/daniel/examples/v8/stanford.exe loaded
The supported file formats are SPARC ELF-32, ELF-64 (MSB truncated to 32-bit addresses), srecord and a.out
binaries. Each section is loaded to its link address. The program entry point of the file is used to set the %PC,
%NPC when the application is later started with run. It is also possible to load binary data by specifying file and
target address using the bload command.
One can use the verify command to make sure that the file has been loaded correctly to memory as below. Any
discrepancies will be reported in the GRMON console.
grmon3> verify v8/stanford.exe
40000000 .text 54.8kB / 54.8kB [===============>] 100%
4000DB30 .data 2.9kB / 2.9kB [===============>] 100%
Total size: 57.66kB (726.74kbit/s)
Entry point 0x40000000
Image of /home/daniel/examples/v8/stanford.exe verified without errors
NOTE: On-going DMA can be turned off to avoid that hardware overwrites the loaded image by issuing the reset
command prior to load. This is important after the CPU has been executing using DMA in for example Ethernet
network traffic.
3.4.3. Running applications
After the application has been uploaded to the target with load the run command can be used to start execution.
The entry-point taken from the ELF-file during loading will serve as the starting address, the first instruction
executed. The run command issues a driver reset, however it may be necessary to perform a reset prior to loading
the image to avoid that DMA overwrites the image. See the reset command for details. Applications already
located in FLASH can be started by specifying an absolute address. The cont command resumes execution after
a temporary stop, e.g. a breakpoint hit. go also affects the CPU execution, the difference compared to run is that
the target device hardware is not initialized before starting execution.
grmon3> reset
grmon3> load v8/stanford.exe
40000000 .text 54.8kB / 54.8kB [===============>] 100%
4000DB30 .data 2.9kB / 2.9kB [===============>] 100%
Total size: 57.66kB (786.00kbit/s)
Entry point 0x40000000
Image /home/daniel/examples/v8/stanford.exe loaded
grmon3> run
Starting
Perm Towers Queens Intmm Mm Puzzle Quick Bubble Tree FFT
34 67 33 117 1117 367 50 50 250 1133
Nonfloating point composite is 144
Floating point composite is 973
CPU 0: Program exited normally.
CPU 1: Power down mode
The output from the application normally appears on the LEON UARTs and thus not in the GRMON console.
However, if GRMON is started with the
-u
switch, the UART is put into debug mode and the output is tunneled
over the debug-link and finally printed on the console by GRMON. See Section 3.9, “Forwarding application
console I/O”. Note that older hardware (GRLIB 1.0.17-b2710 and older) has only partial support for
-u
, it will not
work when the APBUART software driver uses interrupt driven I/O, thus Linux and vxWorks are not supported
on older hardware. Instead, a terminal emulator should be connected to UART 1 of the target system.
Since the application changes (at least) the .data segment during run-time the application must be reloaded before
it can be executed again. If the application uses the MMU (e.g. Linux) or installs data exception handlers (e.g.
eCos), GRMON should be started with
-nb
to avoid going into break mode on a page-fault or data exception.
Likewise, when a software debugger is running on the target (e.g. GDB natively in Linux user-space or WindRiver
Workbench debugging a task) soft breakpoints ("TA 0x01" instruction) will result in traps that the OS will handle
