Forums

Enabling TRACECLK on LPC2292

Started by dpvt December 7, 2006
Greetings:

Can anyone provide information how to enable TRACECLK pin P1.24
output on the LPC2292? This should be simple, yet we are having no
luck getting this pin to oscillate on our custom board.

>From a hardware angle, the LPC2292 user manual states that a 4.7 kohm
resistor between TRACESYNC and Vss will cause pins P1.25-16 to come
up from reset as a trace port. We've tried this solution, but no
TRACECLK output activity is observed.

>From a firmware angle, we've tried setting bits 2 and 3 in PINSEL2.
The user manual states setting these bits should configure pins P1.31-
26 as a debug port and pins 1.25-16 as a trace port. Again, out
TRACECLK output remains static.

Is there something obvious I am overlooking necessary to get TRACECLK
ticking?

Thanks for any hints or suggestions.

Sincerely,
Doug

An Engineer's Guide to the LPC2100 Series

--- In l..., "dpvt" wrote:
>
> Greetings:
>
> Can anyone provide information how to enable TRACECLK pin P1.24
> output on the LPC2292? This should be simple, yet we are having no
> luck getting this pin to oscillate on our custom board.
>
> From a hardware angle, the LPC2292 user manual states that a 4.7 kohm
> resistor between TRACESYNC and Vss will cause pins P1.25-16 to come
> up from reset as a trace port. We've tried this solution, but no
> TRACECLK output activity is observed.
>
> From a firmware angle, we've tried setting bits 2 and 3 in PINSEL2.
> The user manual states setting these bits should configure pins P1.31-
> 26 as a debug port and pins 1.25-16 as a trace port. Again, out
> TRACECLK output remains static.
>
> Is there something obvious I am overlooking necessary to get TRACECLK
> ticking?
>
> Thanks for any hints or suggestions.
>
> Sincerely,
> Doug
>
Have you configured the ETM registers via JTAG? The ETM comes out of
reset powered down with all clocks disabled. According to NXP the ARM
IHI 0014E document provides all the info that you need to work with
the ETM, but the current document on the ARM site appears to have
reached Rev.N now. I have not worked with ETM for a while, and never
on an NXP part, but IIRC it takes a bit of configuration of the ETM
registers before you can start working with trace data at the external
ETM pins.

-- Dave
Actually, we are using Signum Systems JtagJET-Trace (or, more properly,
trying to use). This device provides the expected JTAG debugging
functions through the ETM interface well enough, but they warn if
there's no TRACECLK, there'll be no trace buffer input. Trace
buffering is precisely what we need, and, as I've stated, our LPC2292
shows no sign of activity on its TRACECLK output. Right now, we're
stuck.

At this point, I am tempted to buy one of the half dozen or so
development boards the jtagJET-Trace comes pre-configured for, just to
get a verifiable baseline to work from. I've tried to read these
control files for configuration hints (there's no documentation)
without luck. The Signum Systems folks have been unable to provide us
with a breakthrough, so there is either some highly privileged LPC2292
ETM configuration that we are both missing, or there is something
terribly wrong with our custom hardware (or a bit of both).

Doug
--- In l..., "dpvt" wrote:
>
> Actually, we are using Signum Systems JtagJET-Trace (or, more properly,
> trying to use). This device provides the expected JTAG debugging
> functions through the ETM interface well enough, but they warn if
> there's no TRACECLK, there'll be no trace buffer input. Trace
> buffering is precisely what we need, and, as I've stated, our LPC2292
> shows no sign of activity on its TRACECLK output. Right now, we're
> stuck.
>
> At this point, I am tempted to buy one of the half dozen or so
> development boards the jtagJET-Trace comes pre-configured for, just to
> get a verifiable baseline to work from. I've tried to read these
> control files for configuration hints (there's no documentation)
> without luck. The Signum Systems folks have been unable to provide us
> with a breakthrough, so there is either some highly privileged LPC2292
> ETM configuration that we are both missing, or there is something
> terribly wrong with our custom hardware (or a bit of both).
>
> Doug
>
***If I recall correctly***, you will not see a continuous TRACECLK
output from the ETM. You will only see activity when a trace has been
triggered. So, if your hardware is OK, you *may* only be having a
problem in setting the trigger conditions for the code that you are
testing? You could use some really simple test software with an
infinite loop, and set your trigger conditions to be inside that loop
to produce a continuous ETM trace output??????

If you do not have it yet, the IHI0014N document is available from ARM at:
http://www.arm.com/pdfs/IHI0014N_etm_v34_architecture_spec.pdf
It is 514 pages long!!!!!!!!!!!!!!!

There are also other ETM related documents in:
http://www.arm.com/documentation/Trace_Debug/

-- Dave
Now that is a perspective I had not considered. I have a short
diversion to attend to this morning, but setting a trigger and
observing for trace results is an excellent suggestion. The Signum
System documentation, however, explicitly states that if there is no
TRACECLK, there will be no trace. Hopefully, their statement is
less than accurate.

If your suggestion proves correct, however, a post event trace will
do little for our problem. I have already located conditions that
indicate a problem has occurred. What I require is a record of
events leading up to the problem manifestation.

Thanks also for those document references. I have skimmed them
already. They seem to be intended for people building trace
systems. Since we have bought a trace package, I am unsure how much
low level programming I must affect versus what is provided by the
Signum Systems layer. I shall re-read them in greater detail.

I will provide updates when (or if) breakthroughs present themselves.

doug
--- In l..., "dpvt" wrote:
>
> Now that is a perspective I had not considered. I have a short
> diversion to attend to this morning, but setting a trigger and
> observing for trace results is an excellent suggestion. The Signum
> System documentation, however, explicitly states that if there is no
> TRACECLK, there will be no trace. Hopefully, their statement is
> less than accurate.
>
> If your suggestion proves correct, however, a post event trace will
> do little for our problem. I have already located conditions that
> indicate a problem has occurred. What I require is a record of
> events leading up to the problem manifestation.
>
> Thanks also for those document references. I have skimmed them
> already. They seem to be intended for people building trace
> systems. Since we have bought a trace package, I am unsure how much
> low level programming I must affect versus what is provided by the
> Signum Systems layer. I shall re-read them in greater detail.
>
> I will provide updates when (or if) breakthroughs present themselves.
>
> doug
>

It certainly is true that with no TRACECLK there will be no trace,
since it is required to clock data into the external trace buffer in
your debug hardware. My main experience with ETM was in verifying the
hardware functionality of one of my employer's ASICS that contained an
ARM9, using a Lauterbach Trace32. Since the trace clock originates
from the ARM clock we also had some internal registers to configure
before ETM could be enabled. Also, JTAG has to be used to configure
the ETM for the clock rate and mode before the ETM will be ready to
produce trace data. I assume that Signum integrates their JTAG and ETM
hardware in one debug pod??? I do not think that you will see ANY
TRACECLK activity until all the preceeding steps are completed
successfully. Since I was working from the hardware perspective I used
the simplest possible trigger conditions to get the trace signals to
appear on the external ASIC pins.
I imagine some art will be involved setting up your triggers to find
an event that you do not know the location of, but it is possible.
Just how much trace information that you can capture on a particular
set of trigger conditions will depend a lot on the size and speed of
the trace buffer that your Signum hardware provides. If you overrun
the external trace buffer, trace information will be lost, and your
debugger should warn when/if that happens. That is why I suggested
that you first try things out with some very simple software, just to
gain confidence and experience with the trace hardware.
It's true that the ARM documents seem to be aimed more at folks
implementing the ETM and the debug hardware, but those are the folks
that are ARM's direct customers. Hopefully, that information might
help you in interpreting Signum's documentation?

-- Dave
> It certainly is true that with no TRACECLK there will be no trace,
> since it is required to clock data into the external trace buffer in
> your debug hardware. My main experience with ETM was in verifying
the
> hardware functionality of one of my employer's ASICS that contained
an
> ARM9, using a Lauterbach Trace32. Since the trace clock originates
> from the ARM clock we also had some internal registers to configure
> before ETM could be enabled. Also, JTAG has to be used to configure
> the ETM for the clock rate and mode before the ETM will be ready to
> produce trace data. I assume that Signum integrates their JTAG and
ETM
> hardware in one debug pod??? I do not think that you will see ANY
> TRACECLK activity until all the preceeding steps are completed
> successfully. Since I was working from the hardware perspective I
used
> the simplest possible trigger conditions to get the trace signals to
> appear on the external ASIC pins.
> I imagine some art will be involved setting up your triggers to find
> an event that you do not know the location of, but it is possible.
> Just how much trace information that you can capture on a particular
> set of trigger conditions will depend a lot on the size and speed of
> the trace buffer that your Signum hardware provides. If you overrun
> the external trace buffer, trace information will be lost, and your
> debugger should warn when/if that happens. That is why I suggested
> that you first try things out with some very simple software, just
to
> gain confidence and experience with the trace hardware.
> It's true that the ARM documents seem to be aimed more at folks
> implementing the ETM and the debug hardware, but those are the folks
> that are ARM's direct customers. Hopefully, that information might
> help you in interpreting Signum's documentation?
>
> -- Dave
>
Dave:

Your assumption regarding the Signum pod is correct. Both the JTAG
and the ETM are combined in a single pod. The JTAG functions are
working. I can set break points, single step, and all that good
stuff.

I concur with your assessment that the ETM needs to be configured
through the JTAG port. Precisely how that is accomplished has yet to
be understood, but following a diversionary crisis yesterday, I hope
to re-visit those ETM manuals for additional clues.

Doug
I have googled this TRACECLK issue repeatedly. Piecing together
clues, here is my take on enabling the LPC2292 TRACECLK/P1.24 output
pin.

>From the ETM7 Technical Reference Manual (ARM DDI 0158D), I find the
following:

"3.6.4 Trace signal output timing
The trace connection to the TPA requires a clock, TRACECLK, to be
exported from the ASIC. This is not generated by the ETM7, but must
be generated by the system implimenter."

This confirms my understanding that this signal is sourced from the
LPC2292 itself and is only passed through the ETM. I conclude no
special ETM register programming is required.

As the ARM itself is to generate the required signal, the following
is quoted from Section 22, "Embedded Trace Macrocell", of the
LPC2119/2129/2194/2292/2294 User Manual:

"RESET STATE OF MULTIPLEXED PINS
On the LPC2119/2129/2194/2292/2294, the ETM pin functions are
multiplexed with P1.25-16. To have these pins come as a Trace port,
connect a weak bias resistor (4.7 k Ohm) between the P1.20/TRACESYNC
pin and VSS. To have them come up as port pins, do not connect a bias
resistor to P1.20/TRACESYNC, and ensure that any external driver
connected to P1.20/TRACESYNC is either driving high, or is in high-
impedance state, during Reset."

This statement indicates the core examines the TRACESYNC line at
reset and should come up in trace mode at that time (which I
interpret as including TRACECLK/P1.24 output). Fortunately, in our
application these lines are dedicated to debug and trace not
multiplexed, so that complication is not a factor. We have modified
our board to include the described circuit. Despite this
modification, our TRACECLK remains static.

There are, for those familiar with programming the LPC2292, registers
that configure the processor I/O. There are three Pin Select
registers, but number 2 is of interest. Again, quoting from of the
LPC2119/2129/2194/2292/2294 User Manual, Section 8 "Pin Connect
Block" includes the following table:

Table 64: Pin Function Select Register 2 for LPC2292/2294 (PINSEL2 -
0xE002C014)
PINSEL2 Description Reset Value
bit 1:0 Reserved.
bit 2 When 0, pins P1.36:26 are used as GPIO pins. When 1, P1.31:26
are used as a Debug port.
bit 3 When 0, pins P1.25:16 are used as GPIO pins. When 1, P1.25:16
are used as a Trace port.
...

Programmatically setting bits 2 and 3, however, yields no TRACECLK
output from our LPC2292.

At this stage, I suspect there is one more critical yet unidentified
step required to achieve trace. The instructions quoted here
configure the trace port. These instructions are, however,
critically mute whether they actually start the functions running,
including my long sought after TRACECLK. I would assume, as no
further instructions are documented, the trace functions would
initiate, but that assumption is clearly incorrect.
--- In l..., "dpvt" wrote:
> I have googled this TRACECLK issue repeatedly. Piecing together
> clues, here is my take on enabling the LPC2292 TRACECLK/P1.24 output
> pin.
>
> From the ETM7 Technical Reference Manual (ARM DDI 0158D), I find the
> following:
>
> "3.6.4 Trace signal output timing
> The trace connection to the TPA requires a clock, TRACECLK, to be
> exported from the ASIC. This is not generated by the ETM7, but must
> be generated by the system implimenter."
>
> This confirms my understanding that this signal is sourced from the
> LPC2292 itself and is only passed through the ETM. I conclude no
> special ETM register programming is required.
>

I think that you may have overlooked Figure 3-14 in Section 3.6.4 of
ARM DDI 0158D? The text and schematic in that section shows that while
TRACECLK is *derived* from the ARM MCLK, it is not actually an
unmodified copy of the ARM MCLK. The PWRDOWN bit in the ETM control
register gates the TRACECLK onto the external pin, and it's default
state is OFF. Also, there is a half rate clocking option, which NXP
may or may not have implemented, that controls the TRACECLK which also
needs to be configured by the debug software via JTAG.

-- Dave
> I think that you may have overlooked Figure 3-14 in Section 3.6.4 of
> ARM DDI 0158D? The text and schematic in that section shows that
while
> TRACECLK is *derived* from the ARM MCLK, it is not actually an
> unmodified copy of the ARM MCLK. The PWRDOWN bit in the ETM control
> register gates the TRACECLK onto the external pin, and it's default
> state is OFF. Also, there is a half rate clocking option, which NXP
> may or may not have implemented, that controls the TRACECLK which
also
> needs to be configured by the debug software via JTAG.
>
> -- Dave
>

Hey Dave:

Thanks for the heads up about Figure 3-14. Let me be frank (if you
haven't guessed already) but I'm a software guy, and my hardware
understanding is, as they say, just enough to be dangerous.

I (and my cohorts) had been assuming the LPC2292 TRACECLK (pin P1.24)
was piped right out of the ARM itself and passed through the ETM.
Have we connected the wrong LPC2292 pin to the ETM? I'm not sure.

The Signum folks have provided the schematics of their LPC2138-based
evaluation board, which they state provides the trace functionality.
That document show that chips TRACECLK connected directly into the
ETM TRACECLK, not the system clock. I've just ordered one of those
boards to try to establish a functioning baseline. Hopefully, that
will work and we can reverse engineer that case to our application.

I am soooo confused....

Doug