Use of TRST on ST vs. Luminary ARM JTAG?

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.
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

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

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


Saving a port/pin?

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

Reply to

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.

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'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.

Reply to
Vladimir Ivanov

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

Reply to

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          |
    PC Services
 Click to see the full signature
Reply to

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.

Reply to
Leo Havmøller



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.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.