EMU pins of AM3874

Michi,

Michi Yama said:

According to the datasheet, it is written the below.

* All functions on EMU pins of the device:

     - EMU[1:0] - cross-triggering, boot mode (WIR), STM trace

     - EMU[4:2] - STM trace only (single direction)

However, I would like to know more information regarding EMU pins. How can customer use this pins with JTAG emulator?

See the below links:

http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide#EMU_Pin_Functions

http://processors.wiki.ti.com/index.php/XDS_Connector_Design_Checklist

https://processors.wiki.ti.com/images/5/55/Trace_Header_Design-ext.pdf

http://processors.wiki.ti.com/index.php/Calibrating_XDS560v2_System_Trace_for_STM_Collection

http://processors.wiki.ti.com/index.php/XDS560#XDS560_Rev_D_Cable

http://processors.wiki.ti.com/index.php/Debugging_With_Trace

http://processors.wiki.ti.com/images/7/73/CP_Tracer.pdf

http://processors.wiki.ti.com/index.php/OMAP4_Debug_and_Trace_Tools

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/143237.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/157588.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/161116.aspx

Regards,
Pavel

Michi Yama said:

However, I would like to know more information regarding EMU pins. How can customer use this pins with JTAG emulator?

The EMU pins are part of TI's proprietary debug functionality of their processors, for which unfortunately very little public documentation exists (in sharp contrast to the ARM Coresight debug infrastructure, and the debug functionality of ARM cores in general, all of which is quite well documented; I wish TI would follow ARM's example in that).

Most SoCs do have a Debug chapter in their TRM, though the informativeness thereof varies and is usually quite limited.  The DM814x/AM387x represents an absolute low point here: its TRM has no chapter or section on debug whatsoever.  Fortunately, the TRM of the closely related DM816x/AM389x has a reasonably informative "On-Chip Debug Support" chapter, so I can definitely recommend it as a good source of overview/background information on debug functionality.

As can be inferred from the links Pavel gave, the EMU pins are somewhat multi-purpose and mostly optional.  I'll give some futher comments on the three applications mentioned:

Debug boot mode

(Not to be confused with the boot mode selected by the BTMODE pins)

EMU0 and EMU1 are sampled at power-on reset (POR) and affect global device behaviour, and for normal operation they should both be sampled high (the pins have internal pull-up).

If EMU0 is driven low during POR the device will enter global wait-in-reset state, where the chip infrastructure works normally but all cores are held in reset, including the Cortex-A8.  This gives the debugger time to connect and establish the desired debug configuration, thereby permitting debugging startup from the earliest moment.  This is however somewhat limited by the fact that no debug or trace of the cortex-A8 is possible while it is in secure mode (except on special "EMU"-type devices), so once it is released from reset it will run freely until it halts after entering non-secure mode at the start of public rom code (PC = 0x20000), at which point full debugging becomes available.

Global WiR also allows you to explore the device before any initialization (even by secure rom) or other activity has happened, which to me feels a bit eerie as if walking through a ghost-town.  The fact that you need to manually enable things which are normally always on (even the Control module!) probably contributes to that feeling. ;-)

For the DM81xx/AM38xx chips, EMU1 should always be high during POR: the modes with EMU1 low are (as far as I know) either unused or solely for internal testing purposes.

System trace

After POR, the EMU pins are unused (or in case of EMU2-4 used for video out) until configured for some debug purpose.  The main such purpose (and for EMU2-4 the only purpose) is for system trace, which allows trace messages from various sources to be collected in real-time if you have a sufficiently fancy debugger (e.g. the XDS560v2).

Note that on the DM81xx/AM38xx processors, trace data from the Cortex-A8 ETM and the C674x DSP can only be collected into the embedded trace buffer (ETB).  Only the system trace module (MIPI-STM) supports output to the EMU pins (it also supports output to the ETB as alternative).

A noteworthy feature is that trace data from the HDVICP subsystem and the OCP-WP module uses a separate interconnect (L3_INSTR) to reach the system trace module, allowing completely non-intrusive performance analysis since no additional traffic is generated on the main L3 interconnect.  Documentation on these features is however, again, scarce.  Also, the HDVICP subsystem is not present on the AM387x.

Cross-triggering

This function is used for synchronized multi-core debugging (see e.g. here and here).  Normally this doesn't involve the external EMU pins: cross-triggering is performed between different cores of the same SoC.  However, the EMU0-1 pins can be used to extend this beyond the chip boundary and perform cross-triggering between multiple devices.  No idea how this would be set up though.

You can get some idea of the possibilities of cross-triggering signals by browsing the "Cross Trigger Interface" chapter of the Cortex-A8 TRM.  In theory, very elaborate triggering configurations are possible which may be useful if you're trying to hunt done some elusive bug which only happens under rare circumstances.

Using EMU0-1 for external cross-triggering can be combined with system trace, at the cost of reducing the maximum rate of trace data.

I hope this info somewhat clarifies the mysterious EMU pins for you!