GR712RC-UM, Jun 2017, Version 2.9 16 www.cobham.com/gaisler
GR712RC
Uncorrectable SDRAM errors are expected to be a rare occurrence, provided that scrubbing of cor-
rectable errors has been implemented in the system.
The uncorrected error response may be the result of a processor access which leads to the processor
taking a trap. The read of the trap table may then occur during the window when the FTMCTRL per-
forms the extra read access which leads to erroneous data or a AMBA ERROR response when the
processor fetches the trap table. In multi-master systems, one master may trigger the uncorrectable
error and a second master may perform a read access in the window where the FTMCTRL is malfunc-
tioning.
There are cases where the unintended read access is prevented. A SDRAM command issue or a
refresh operation are cases that prevent triggering the erratum.
It is recommended that all GR712RC systems implement the following workaround.
Workaround
The erratum cannot be triggered when the MCFG2.TRP field (bit 30 of MCFG2 register) is set to 1
(SDRAM t
RP
parameter is three clock cycles).
VxWorks board support package for GR712RC will be updated to default MCFG2.TRP=1. For other
boot loaders, please refer to the software package’s documentation for information on how to set
MCFG2.TRP.
GRMON2 will be updated to automatically set MCFG2.TRP for GR712RC.
Please contact Cobham Gaisler support for information on specific software versions.
Other information
The failure will not occur if the second incoming access is to the PROM, SRAM or IO area. The
memory controller may perform the unintended read access to SDRAM but software will not be
affected.
The bug does not affect SRAM and PROM areas.
The controller will always perform the unintended SDRAM read access when MCFG2.TRP=0,
unless there is a refresh operation pending.
It takes exactly five system clock cycles after the AMBA ERROR response until the memory control-
ler is back in normal state.
1.7.10 MIL-STD-1553B core duplicate interrupt assertion
Under certain conditions interrupts from the MIL-STD-1553B core can appear to be duplicate. The
Interrupt Pending status bit in the Multiprocessor Interrupt Controller might be asserted an extra time
after the interrupt event is successfully processed. The problem appears more frequently with a higher
ratio of the AHB system bus frequency to the MIL-STD-1553B core frequency, but can be present for
any combination thereof. A possible consequence of this problem is that the Interrupt Service Routine
associated with the MIL-STD-1553B core, IRQ 14, gets called twice.
The reason for this spurious behavior lies in how the Actel Core1553BRM controller propagates the
IRQ to the interrupt controller. The IRQ line is propagated from the Interrupt Request pulse from the
Core1553BRM and is re-synchronized into the system clock domain and fed as an IRQ source to the
interrupt controller. Assuming, for instance, an AHB system bus frequency four times higher than the
MIL-STD-1553B core frequency, since the Interrupt Request line output of the Core1553BRM is
high for 3 cycles when INTLEVEL=0, this will result in a 12 cycle pulse coming in to the interrupt
controller. When this pulse is longer than it takes for the CPU to handle the interrupt, this will lead to
a second interrupt being stored into the interrupt controller, and this will then cause the interrupt han-
dler to be called twice.
Workaround
A possible workaround is to manually clear the interrupt pending status in the IRQ handler via the
Interrupt Clear Register of the IRQ controller. This assumes that there are no other other sources
(hardware or software) that can assert interrupt 14. This needs to be done early, before reading the
BRM IRQ status/log to eliminate the risk of losing any IRQ events from the BRM.
The other workaround is simply to accept the extra IRQs and make the IRQ handler capable of han-
dling this case.
To Next Page
Loading...
Need help?
General
