AM4378: Questions on JTAG operation

EMU[1:0] and all JTAG signals are required to perform basic debug functions with 1-bit trace, where trace data is transferred via the EMU[1:0] signals. Trace throughput can be doubled using 2-bit trace, which requires one additional EMU[2] signal. Trace throughput doubles again using 4-bit trace, which requires two more EMU[4:3] signals. Trace throughput continues to increase as you connect more EMU signals to the debugger. I'm not familiar with the various debuggers and their software, but assume debugger which support trace allow you to configure the number of EMU signals connected.

Note: All of the EMU signals are multiplexed with other signal functions. So the number if EMU signals available for trace is very dependent on your system usage of pins that have EMU signal functions multiplexed to them.

External pull-up resistors are required for the EMU[1:0] pins, but not aware of any AM437x pull specific requirements other than you should not allow signals to float.

Please highlight your specific concerns related to differences in connection recommendations.

The maximum JTAG clock frequency supported by AM437x is 16.67MHz. However, other timing constraints may further limit the actual max operating frequency. The AM437x datasheet defines JTAG timing requirement parameters and switching characteristic parameters. The system designer is required to perform a timing analysis to confirm maximum operating frequency of the interface and any signal length constraints. The analysis must confirm all timing requirements of both AM437x and the attached debugger are meet when applying the appropriate switching characteristics while including actual PCB/cable delays in the analysis. Note: Most setup time violations and/or hold time violations can be resolved by reducing the JTAG clock frequency since data is transmitted on one edge of the clock and data is captured on the other edge of the clock. I recommend trace length matching of +/- 1 inch.

The JTAG interface is not a fast interface, so no major concerns with respect to impedance matching. As mentioned above the clock frequency can be reduced to provide more setup/hold time, which is an option for resolving timing related signal integrity issues like ringing. However, you need to make sure the clock signal does not have any non- monotonic transitions. Non-monotonic events that occur between VIL and VIH may introduce glitches that have a chance of over-clocking synchronous circuits, which cause these circuits to do unpredictable things. So you may find it helpful to use series source termination near the clock source and make sure there are no stubs on the clock signal trace.

I’m not able to answer question related to using CCS, so will assign this thread to someone else that may be able to answer your other questions.

Regards,
Paul

peaves said:

I’m not able to answer question related to using CCS, so will assign this thread to someone else that may be able to answer your other questions.

Hi Lauren,

I'll need to hop into the office to grab my AM437x target so I can investigate further. I plan on going into the office tomorrow. 

Thanks

ki

One comment on trace.  If you are wanting to output trace to pins then you need the TMDSEMUPROTRACE receiver and not just a regular XDS560v2.  The XDS560v2 STM has a system trace receiver for some older devices but it does not support CPU trace to pins.

You can use trace with any XDS debug probe if you are capturing trace to the embedded trace buffer.  In this scenario, CCS reads the ETB and decodes it when halted.  

Regards,

John

Lauren Mayfield said:

 Issue

• They can connect to the target, load symbols, and see the stopped execution steps on the target
• If they pause the target, after waiting for a couple of seconds, the target continues executing without user intervention
• In addition, hardware tracing does not seem to work, it only displays output when the processor is hung on an instruction
• CCS also frequently becomes unresponsive and must be restarted. Turning off the target and disconnecting the JTAG rarely fixes the issue
• They've slowed down the clock speed to its lowest setting with the same results

I set up an environment running CCSv9.2 connected to an AM437x IDK target via both Blackhawk and Spectrum Digital XDS560v2 STM JTAG probes in a Ubuntu 16.04 VM.

I do not see the issue where the target continues executing without user intervention.

I also have no issues using the Hardware Trace Analyzer to collect PC Trace data. I am able to collect trace data without issue.

I do occasionally get issues where CCS is unresponsive - though most of the time CCS will eventually come back. There was one time where I did have to force terminate CCS however.

Note that running CCS Inside a VM is not an officially supported environment. While many people successfully have used CCS in a VM (including myself and others in TI), it is not an environment that has been properly tested. We always encourage using a native environment when possible. Also, CCS 9.2 is an older release that is no longer supported. 

If the customer can provide a simple but reproducible test case, we can investigate further. But I would also suggest that the customer try updating their environment (both Ubuntu and CCS) if possible.

Thanks

ki