Use of TRST on ST vs. Luminary ARM JTAG?

[Tim Wescott]

I'm using an ST ARM Cortex part for the first time. I've been using
Luminary parts until now.

I notice that on the Olimex demo board for the STM32F103RBT6, they have
the JTAG TRST pin connected, but on the Luminary eval board for the
LM3S811 the TRST pin is left open.

Does anyone know why this is? Is it just that the TRST pin is sorta
optional, and the Luminary folks weren't in a mood to dot all their 'i's
and cross all their 't's? Is there some reason that you might _not_ want
to connect TRST?

I also see that the Olimex board has a solderable bridge to connect TRST
to the processor reset. Again -- why, do you know the advantages and
disadvantages?

I'm going to just copy the Olimex board, but I'm curious as to just what
it is that I am so blindly doing...

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

[linnix]

On Feb 10, 10:10 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> I'm using an ST ARM Cortex part for the first time.  I've been using
> Luminary parts until now.
>
> I notice that on the Olimex demo board for the STM32F103RBT6, they have
> the JTAG TRST pin connected,

Good idea, since you want the CPU reset/halted while programming the
flash.

> but on the Luminary eval board for the
> LM3S811 the TRST pin is left open.
>
> Does anyone know why this is?  Is it just that the TRST pin is sorta
> optional,

Yes, it should be optional. Jtag I/O chains should not be affected by
CPU state.

> and the Luminary folks weren't in a mood to dot all their 'i's
> and cross all their 't's?  Is there some reason that you might _not_ want
> to connect TRST?

Saving a port/pin?

>
> I also see that the Olimex board has a solderable bridge to connect TRST
> to the processor reset.  Again -- why, do you know the advantages and
> disadvantages?

Not a good idea. Processor reset is usually tied to high capacitive
load. That's probably not good for the debugger driver.

[Vladimir Ivanov]

On Sat, 11 Feb 2012, Tim Wescott wrote:

> I'm using an ST ARM Cortex part for the first time. I've been using
> Luminary parts until now.
>
> I notice that on the Olimex demo board for the STM32F103RBT6, they have
> the JTAG TRST pin connected, but on the Luminary eval board for the
> LM3S811 the TRST pin is left open.
>
> Does anyone know why this is? Is it just that the TRST pin is sorta
> optional, and the Luminary folks weren't in a mood to dot all their 'i's
> and cross all their 't's?

TRST is sorta ptional. It's the IC designer's decision whether they
implement it and user's decision whether to use it. You get to the same
TAP state with just 5 (IIRC) clocks when TMS=1.

> Is there some reason that you might _not_ want to connect TRST?

Some ICs don't have it. Also if you want less signals in a JTAG
header/cable.

Perhaps there might be reasons _to_ connect it.

> I also see that the Olimex board has a solderable bridge to connect TRST
> to the processor reset. Again -- why, do you know the advantages and
> disadvantages?

I'd guess a configuration for a certain cable/software which would use it
for hard MCU reset. It won't be TRST anymore, just using the cable wire.

Some cables have separate MCU reset signal - perhaps this covers some that
do not.

[MK]

On 11/02/2012 06:10, Tim Wescott wrote:
> I'm using an ST ARM Cortex part for the first time. I've been using
> Luminary parts until now.
>
> I notice that on the Olimex demo board for the STM32F103RBT6, they have
> the JTAG TRST pin connected, but on the Luminary eval board for the
> LM3S811 the TRST pin is left open.
>
> Does anyone know why this is? Is it just that the TRST pin is sorta
> optional, and the Luminary folks weren't in a mood to dot all their 'i's
> and cross all their 't's? Is there some reason that you might _not_ want
> to connect TRST?
>
> I also see that the Olimex board has a solderable bridge to connect TRST
> to the processor reset. Again -- why, do you know the advantages and
> disadvantages?
>
> I'm going to just copy the Olimex board, but I'm curious as to just what
> it is that I am so blindly doing...
>

The Keil Ulink interface supports JTAG and the ARM SW debug interface.
SW uses fewer pins and works at least as well. Keil suggest connecting
the reset pin which can be used to reset the processor from the
debugger. If the software (on the target) sets the target clock to
something useless (like off or too fast or very slow) JTAG won't work
any more so being able to reset from the debug port is very useful.

Michael Kellett

[Paul]

In article <72d28323-3df6-40aa-a70d-
b425f6...@d15g2000yqg.googlegroups.com>, m...@linnix.info-for.us
says...

>
> On Feb 10, 10:10 pm, Tim Wescott <t...@seemywebsite.com> wrote:
> > I'm using an ST ARM Cortex part for the first time.  I've been using
> > Luminary parts until now.
> >
> > I notice that on the Olimex demo board for the STM32F103RBT6, they have
> > the JTAG TRST pin connected,
>
> Good idea, since you want the CPU reset/halted while programming the
> flash.
>
> > but on the Luminary eval board for the
> > LM3S811 the TRST pin is left open.
> >
> > Does anyone know why this is?  Is it just that the TRST pin is sorta
> > optional,
>
> Yes, it should be optional. Jtag I/O chains should not be affected by
> CPU state.
>
> > and the Luminary folks weren't in a mood to dot all their 'i's
> > and cross all their 't's?  Is there some reason that you might _not_ want
> > to connect TRST?
>
> Saving a port/pin?
>
> >
> > I also see that the Olimex board has a solderable bridge to connect TRST
> > to the processor reset.  Again -- why, do you know the advantages and
> > disadvantages?
>
> Not a good idea. Processor reset is usually tied to high capacitive
> load. That's probably not good for the debugger driver.

If used in debugger more likely the equivalent of a switch to target 0V
a FET capable of a few 100mA or more is very easy to implement as many
in tiny package are capable of 2A - 5A Id.

Switching speed is not a problem as long as it discharges the cap and
reset time compared to switching time is orders of magnitude different.

The only problem you have is if the MCU reset pin is driven by an
active device like a reset controller that has push-pull output
stage, not very common. Someone may distribute their reset signal
through a buffer of some kind not open drain/collector drive.



--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

[Leo Havmøller]

> the reset pin which can be used to reset the processor

OP asked about TRST, which is different from the processor reset pin.
TRST resets the JTAG block.
It is optional, since JTAG reset state can be guaranteed by setting TMS high
and providing 6 TCK's.
Some chips uses TSRT to power on the JTAG block.
Chips without TRST usually have a command via JTAG to reset the processor.

Leo Havmøller.

[Andy]

Depending on the chip, sometimes, the TRST pin will also reset the CPU
core or some portion of the SoC. I've also run into a chip where the
jtag block behaved differently depending on whether it was reset via 5
TCLKs with TMS high or via TRST. Also the treatment of a default
state for TRST is different for different SOCs - some want it pulled
high, others low.

Where possible I've taken to providing a series R between the
connector and chip, and sites for pullups and pulldowns just to have
options.