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

GRMON3-UM
June 2019, Version 3.1.0
75 www.cobham.com/gaisler
The info sys command displays information on the configured burst length of the scrubber.
memscrub0 Cobham Gaisler AHB Memory Scrubber
AHB Master 1
AHB: FFE01000 - FFE01100
IRQ: 28
burst length: 32 bytes
6.16. MIL-STD-1553B Interface
The info sys command displays the enabled parts of the core, and the configured codec clock frequency. The
GR1553B core is accessed using the command mil, see command description in Appendix B, Command syntax
for more information.
gr1553b0 Cobham Gaisler MIL-STD-1553B Interface
APB: FFA02000 - FFA02100
IRQ: 26
features: BC RT BM, codec clock: 20 MHz
Device index: 0
Examining data structures
The mil bcx and mil bmx commands prints the contents of memory interpreted as BC descriptors or BM entries,
in human readable form, as seen in Example 6.4.
Example 6.4.
grmon3> mil bcx 0x40000080
Address TType RTAddr:SA WC Bus Tries SlTime TO Options Result vStat BufPtr
========== ===== =========== == === ======= ====== == ======= ======= ==== ========
0x40000080 BC-RT 05:30 1 B 01:Same 0 14 s NoRes 1 0000 40000000
0x40000090 RT-BC 05:30 1 B 01:Same 0 14 s [Not written] 40000040
0x400000a0 BC-RT 05:30 2 B 01:Same 0 14 s [Not written] 40000000
0x400000b0 RT-BC 05:30 2 B 01:Same 0 14 s [Not written] 40000040
0x400000c0 BC-RT 05:30 3 B 01:Same 0 14 s [Not written] 40000000
0x400000d0 RT-BC 05:30 3 B 01:Same 0 14 s [Not written] 40000040
0x400000e0 BC-RT 05:30 4 B 01:Same 0 14 s [Not written] 40000000
Data transfers
If the GR1553B core is BC capable, you can perform data transfers directly from the GRMON command line. The
commands exist in two variants: mil get and mil put that specify data directly on the command line and through
the terminal, and mil getm and mil putm that sends/receives data to an address in RAM.
In order to perform BC data transfers, you must have a temporary buffer in memory to store descriptors and data,
this is set up with the mil buf command.
The data transfer commands use the asynchronous scheduling feature of the core, which means that the command
can be performed even if a regular BC schedule is running in parallel. The core will perform the transfer while
the primary schedule is idle and will not affect the schedule. It can even be run with BC software active in the
background, as long as the software does not make use of asynchronous transfer lists.
If the primary schedule blocks the asynchronous transfer for more than two seconds, the transfer will be aborted
and an error message is printed. This can happen if the running schedule does not have any slack, or if it is stuck
in suspended state or waiting for a sync pulse with no previous slot time left. In this case, you need to stop the
ordinary processing (see mil halt) and retry the transfer.
Temporary data buffer
Many of the mil subcommands need a temporary data buffer in order to do their work. The address of this buffer
is set using the mil buf command and defaults to the start of RAM. By default the driver will read out the existing
contents and write it back after the transfer is done, this can be changed using the mil bufmode command.
If the core is on a different bus where the RAM is at another address range, the scratch area address in the core’s
address space should be given as an additional
coreaddr
argument to the mil buf command.
Halting and resuming
The mil halt command will stop and disable the RT,BC and BM parts of the core, preventing them from creating
further DMA and 1553 bus traffic during debugging. Before this is done, the current enable state is stored, which
allows it to later be restored using mil resume. The core is halted gracefully and the command will wait for current
ongoing transfers to finish.