Public Version
www.ti.com
L3 Interconnect
–
CONTROL.CONTROL_PROT_ERR_STATUS [05]: MAD2D protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS [06]: IVA2.2 protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS [07]: L4-Core protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS [12]: L3 RT protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS [15]: SAD2D protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS [16]: L4-Per protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS [17]: L4-Emu protection violation
•
In debug mode:
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [00]: OCM-ROM protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [01]: OCM-RAM protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [02]: GPMC protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [03]: SMS protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [05]: MAD2D protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [06]: IVA2.2 protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG [12]: L3 RT protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG[16]: L4-Per protection violation
–
CONTROL.CONTROL_PROT_ERR_STATUS_DEBUG[17]: L4-Emu protection violation
When a violation occurs, these bits are cleared when the L3 or L4 firewall embedded error log registers
are cleared.
9.2.3.4
Error Handling
9.2.3.4.1 Error Detection and Logging
The L3 interconnect provides mechanisms for the detection, logging, and distribution of module-detected
and internal interconnect errors. Hardware support is provide to assist in logging errors and cleaning up
the state to allow error recovery software to run.
Two types of errors are identified by the L3 interconnect:
•
Errors detected by modules and passed along by the interconnect:
–
SResp error: Using the SResp in-band qualifier from the target, the initiator is informed that its
request was unsuccessful (see
). This error is nonspecific and further analysis is required
to find its cause.
–
SError: This out-of-band qualifier reports that the target is denied service due to an internal cause.
No further analysis can be done in the L3 itself.
•
Errors detected by the L3 interconnect:
–
Unsupported command: This error repports that the initiator sent a command that cannot be
processed, because the target cannot accept it and no conversion to another command is possible.
This error is detected only once per burst.
–
Address hole: This error reports an unknown address for a request. The address map is local to
each IA; therefore, an address hole error is reported each time an initiator requests an access to a
target it is not logically connected to, even if this address exists in the global L3 address map. This
error is detected only once per burst.
–
Protection violation: This error indicates a request was rejected by a firewall.
–
Requests time-out: This error reports that the target did not accept (if no response expected) or did
not respond to the request presented by the interconnect TA. In this case, all new requests to this
TA will be answered with SResp = ERR.
–
Response time-out: This error reports that the initiator did not accept response from the
interconnect IA in the correct time interval (applies only to masters that have response flow control
capabilities). In this case, the IA sends burst close transactions to TAs that have open transactions
from this IA. Any new request from this initiator is refused.
–
Burst open time-out: This error reports that a burst or ReadEx/Write pair has been started to the
interconnect IA by the initiator but did not finish in the correct time interval. If the time interval for
any command exceeds the time-out period, a time-out occurs. The initiator does not complete a
burst or ReadEx/Write pair. The interconnect IA then closes the transaction by a burst close
2013
SWPU177N – December 2009 – Revised November 2010
Interconnect
Copyright © 2009–2010, Texas Instruments Incorporated
