EasyManua.ls Logo

COBHAM GRMON3 - User Defined Debug Link; Api

COBHAM GRMON3
239 pages
Print Icon
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
GRMON3-UM
June 2019, Version 3.1.0
62 www.cobham.com/gaisler
The GRESB routing tables for the SpaceWire port and the TCP port that will be used must also be configured.
The routing tables can be setup via the web interface or using the software distributed with the GRESB. All the
node addresses in the routing table for the SpaceWire port must be configured to forward packets to the TCP port
without any header deletion. The routing table for the TCP port must be setup in the same way but to forward the
packets from all nodes to the SpaceWire port instead. A Linux bash script and a Windows bat-script is provided
with GRMON professional distribution in folder share/grmon/tools, that can be used with the GRESB
software to setup the routing tables. The scripts must be able to find the GRESB software, so either the PATH
environment variable must be setup or execute the scripts from the GRESB software folder.
GRESB separate routing table mode shall be used when connecting to the AGGA4 SpaceWire debug link. This
can be configured in the GRESB web interface: "Routing table configuration"->"Set/view Mode"->"Set Separate
mode".
5.6. User defined debug link
In addition to the supported DSU communication interfaces (Serial, JTAG, ETH and PCI), it is possible for the
user to add a custom interface using a loadable module. The custom DSU interface must provide functions to read
and write data on the target system’s AHB bus.
Extra options for the user defined connection:
-dback <filename>
Use the user defined debug link. The debug link should be implemented in a loadable module pointed out
by the filename parameter.
-dbackarg <arg>
Set a custom argument to be passed to the user defined debug link during start-up.
5.6.1. API
The loadable module must export a pointer variable named DsuUserBackend that points to a struct ioif,
as described below:
struct ioif {
int (*wmem) (unsigned int addr, const unsigned int *data, int len);
int (*gmem) (unsigned int addr, unsigned int *data, int len);
int (*open) (char *device, int baudrate, int port);
int (*close) ();
int (*setbaud) (int baud, int pp);
int (*init) (char* arg);
};
struct ioif my_io = {my_wmem, my_gmem, NULL, my_close, NULL, my_init};
struct ioif *DsuUserBackend = &my_io;
On the Linux platform, the loadable module should be compiled into a library and loaded into GRMON as follows:
> gcc -fPIC -c my_io.c
> gcc -shared my_io.o -o my_io.so
> grmon -dback my_io.so -dbackarg "my argument"
On the Windows platform, the loadable module should be compiled into a library and loaded into GRMON as
follows:
> gcc -c my_io.c
> gcc -shared my_io.o -o my_io.dll
> grmon -dback my_io.dll -dbackarg "my argument"
The members of the struct ioif are defined as:
int (*wmem) (unsigned int addr, const unsigned int *data, int len);
A function that performs one or more 32-bit writes on the AHB bus. The parameters indicate the AHB
(start) address, a pointer to the data to be written, and the number of words to be written. The data is in
little-endian format (note that the AMBA bus on the target system is big-endian). If the len parameter is
zero, no data should be written. The return value should be the number of words written.
int (*gmem) (unsigned int addr, unsigned int *data, int len);
A function that reads one or more 32-bit words from the AHB bus. The parameters indicate the AHB (start)
address, a pointer to where the read data should be stored, and the number of words to be read. The returned

Table of Contents