GR712RC-QSG
November 2018, Version 1.0
23 www.cobham.com/gaisler
"proprietary" interface is obsolete and not part of the public interface of the GR712RC but are still part of the
I/O switch matrix.
When the CAN interface is enabled, the pins 191, 190, 185, 184 and 172 are also driven with "random values"
unless these pins are assigned to an interface with higher I/O switch matrix priority, such as when the MIL-
STD-1553B interface is enabled. Of these pins, 191, 190 and 185 are shared with Ethernet (RMII) and there is
the conflict.
Ethernet has lower switch matrix priority than CAN. So when CAN is enabled, the pins 191, 190 and 185 are not
driven by the Ethernet controller.
GPIO bits 13...16 are unavailable when CAN or SPW-2 is enabled. GPIO pins always has lowest priority in the
switch matrix.
How a particular device is "enabled" with regard to the switch matrix is described in [RD-2], Table 9. Most devices
are I/O-enabled by the clock gating unit and some are enabled via device control registers.
5.13. Hardware behavior at CPU reset and power management
GR712RC has the following behavior with regard to how the power-down mode and program counter (PC) is
managed:
• At GR712RC power-on, and at system reset issued by asserting RESETN (including watchdog), the following
is done:
• CPU0 sets PC=0 and starts execution.
• CPU1 sets PC=0 and is powered down.
• A CPU enters power-down mode by writing to its own CPU local register %ASR19. The local PC is set to
the instruction following the %ASR19 write.
• A CPU can not power down another CPU.
• Any CPU can read the power-down status of any other CPU by reading the Multiprocessor status register
in the interrupt controller.
• Any CPU can resume execution on any other CPU by writing to the Multiprocessor status register in the
interrupt controller.
• When a CPU is being resumed (powered up) by a write to the Multiprocessor status register, it continues
executing at its current PC.
• If an (unmasked) interrupt occurs on a powered down CPU, then the target CPU resumes execution on the
current PC.
The above behavior has some implications with regard to how processors have to cooperate on software initiated
restart.
At power-on, the RESETN signal is engaged and thus the PC for CPU1 has a good known value. No specific
preparations on CPU1 has to be performed for power-on.
For a software-initiated restart of the system, all processors need to synchronize before issuing the restart. All
processors except for CPU0 should typically be powered down and the other processors should resume execution
in memory which is guaranteed to exist as soon as they are resumed. This is because the currently executed appli-
cation and its data (in RAM) will typically disappear when CPU0 performs low-level initialization initialization
of memory controller and clearing RAM.
To solve this for the secondary processors, a dedicated “parking routine” in ROM could be entered by secondary
processors before CPU0 performs the software-initiated restart.