Public Version
SDTI Module
www.ti.com
27.3.4.2.4 Claim Resets
When the SDTI is owned by the debugger, the resource is released if the debugger is disconnected.
If the SDTI is owned by the application and the processor enters debug state, the resource continues to
belong to the application. The SDTI is not sensitive to debug state.
If the SDTI ownership is released while data are in the SDTI FIFO, the serial interface continues to export
data until the FIFO is drained.
27.3.4.3 Trace Data Collection
The messages allow the application software to export, through the serial trace interface, key information
that provides high-level visibility on system behavior (task entry, system status, test signature, and
memory allocation); 256 message channels are available, starting at 0x5460 0000.
To minimize cycle overhead, the generation of messages is implemented through a dedicated address
window. Each write to an address within the window triggers a message.
To facilitate memory management unit (MMU) use for channel enabling and disabling, channel to memory
address mapping is organized as follows:
•
Each of the 256 channels is allocated 4KB of memory. This corresponds to an MMU page.
•
Within 4KB, CPU1 and CPU2 channels are interleaved:
–
1KB CPU1 message
–
1KB CPU1 timestamped message
–
1KB CPU2 message
–
1KB CPU2 timestamped message
•
Each write to addresses within the first KB of channel space triggers a CPU1 message.
•
Each write to addresses within the second KB of channel space triggers a CPU1 timestamped
message.
•
Each write to addresses within third KB of channel space triggers a CPU2 message.
•
Each write to addresses within fourth KB of channel space triggers a CPU2 timestamped message.
When there is a write in that range, SDTI hardware decodes the access and stores the address decoded
as channel, CPU1/2, and message/ timestamped message, along with the data and access size.
The message header is determined from the accessed address and access type (1, 2, or 4 bytes).
Trace matching for CPU1 and CPU2 message generation can be globally enabled or disabled in the
register.
Although timestamped messages are supported, the SDTI does not implement time-stamping logic, and
all time-stamp-related bit fields in timestamped message are always zeroed.
Timestamped messages can be used as an end message marker. Trace software generates a
timestamped message on the same channel with previously exported non-timestamped messages as an
end message marker.
There is no MConn-ID supported on L4_EMU and thus no capability to differentiate accesses from various
initiators. Each access to the CPU1 address space generates a CPU1 message/ timestamped message,
regardless of the initiator. The same applies for CPU2 message generation.
Debugger accesses are differentiated from other initiators by using the MRegDebug qualifier. If enabled
through the
[2] DEBUGGERTRACEEN bit, debugger accesses to the trace matching
window generate a CPU1 or CPU2 message, depending only on the address accessed. The external
trace receiver cannot differentiate between debugger-initiated and application-initiated trace. Otherwise,
debugger writes to the trace matching address window do not generate messages.
Burst writes not supported by L4_EMU burst from level 3 (L3) are split into single writes in the L3/L4_EMU
bridge (for example, originating from STM instruction), with each of them triggering a separate message.
3614
Debug and Emulation
SWPU177N – December 2009 – Revised November 2010
Copyright © 2009–2010, Texas Instruments Incorporated
