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

GRMON3-UM
June 2019, Version 3.1.0
76 www.cobham.com/gaisler
The state preserved between mil halt and mil resume are:
• BC schedules' (both primary and async) states and next positions. If schedule is not stopped, the last transfer
status is also preserved (as explained below)
• BC IRQ ring position
• RT address, enable status, subaddress table location, mode code control register, event log size and position
• BM enable status, filter settings, ring buffer pointers, time tag setup
State that is not preserved is:
• IRQ set/clear status
• BC schedule time register and current slot time left.
• RT bus words and sync register
• RT and BM timer values
• Descriptors and other memory contents
For the BC, some extra handling is necessary as the last transfer status is not accessible via the register interface.
In some cases, the BC must be probed for the last transfer status by running a schedule with conditional suspends
and checking which ones are taken. This requires the temporary data buffer to be setup (see mil buf).
Loop-back test
The debug driver contains a loop-back test command mil lbtest for testing 1553 transmission on both buses be-
tween two devices. In this test, one of the devices is configured as RT with a loop-back subaddress 30. The other
device is configured as BC, sends and receives back data with increasing transfer size up to the maximum of 32
words.
The mil lbtest command needs a 16K RAM scratch area, which is either given as extra argument or selected using
the mil buf command as described in the previous section.
Before performing the loop-back test, the routine performs a test of the core’s internal time base, by reading out
the timer value at a time interval, and displays the result. This is to quickly identify if the clock provided to the
core has the wrong frequency.
In the RT case, the command first configures the RT to the address given and enables subaddress 30 in loop-
back mode with logging. The RT event log is then polled and events arriving are printed out to the console. The
command exits after 60 seconds of inactivity.
In the BC case, the command sets up a descriptor list with alternating BC-to-RT and RT-to-BC transfers of in-
creasing size. After running through the list, the received and transmitted data are compared. This is looped twice,
for each bus.
6.17. PCI
The debug driver for the PCI cores are mainly useful for PCI host systems. It provides a command that initializes
the host. The initialization sets AHB to PCI memory address translation to 1:1, AHB to PCI I/O address translation
to 1:1, points BAR1 to 0x40000000 and enables PCI memory space and bus mastering, but it will not configure
target bars. To configure the target bars on the pci bus, call pci conf after the core has been initialized. Commands
for scanning the bus, disabling byte twisting and displaying information are also provided.
The PCI cores are accessed using the command pci, see command description in Appendix B, Command syntax
for more information. Supported cores are GRPCI, GRPCI2 and PCIF.
The PCI commands have been split up into several sub commands in order for the user to have full control over
what is modified. The init command initializes the host controller, which may not be wanted when the LEON target
software has set up the PCI bus. The typical two different use cases are, GRMON configures PCI or GRMON scan
PCI to viewing the current configuration. In the former case GRMON can be used to debug PCI hardware and
the setup, it enables the user to set up PCI so that the CPU or GRMON can access PCI boards over I/O, Memory
and/or Configuration space and the PCI board can do DMA to the 0x40000000 AMBA address. The latter case
is often used when debugging LEON PCI software, the developer may for example want to see how Linux has
configured PCI but not to alter anything that would require Linux to reboot. Below are command sequences of
the two typical use cases on the ML510 board: