On Friday 20 January 2006 21:10, Ed Schlunder wrote: > The real Wiggler has host control of the TRST.
Even if the TAP
> controller can be reset by a TCK sequence, wouldn't the Macraigor
> OCDremote software likely implement support for reseting the TAP
> controller only through the TRST signal and omit support for doing a
> special TCK reset sequence? I wonder if this could explain why people
> say that they have trouble with OCDremote while the OpenOCD software
> works better. Does OpenOCD support the special TCK sequence for
> reseting the TAP controller?
>
OpenOCD allows you to specify what reset configuration your jtag interface and
your target offers: none, trst only, srst only, srst and trst, and the
possibility that trst might pull srst (just for completeness), that srst
pulls trst (lpcs behave that way, i.e. a system reset resets the test logic,
too) or that both reset lines are combined.
If a reset configuration is specified that lacks trst, OpenOCD automatically
uses the tck sequence.
If there's anything you're missing feel free to contact me, and
I'll try to
get it fixed.
The real Wiggler has host control of the TRST. Even if the TAP
controller can be reset by a TCK sequence, wouldn't the Macraigor
OCDremote software likely implement support for reseting the TAP
controller only through the TRST signal and omit support for doing a
special TCK reset sequence? I wonder if this could explain why people
say that they have trouble with OCDremote while the OpenOCD software
works better. Does OpenOCD support the special TCK sequence for
reseting the TAP controller?
In other news, I'm starting to read up on the RTCK pin. The LPC2103
preliminary user's manual, section 20.5 says:
"On the LPC2101/02/03, the pins TMS, TCK, TDI, TDO, and TRST are
multiplexed with P0.27 - P0.31. To have them come up as a Debug port,
connect a weak bias resistor (4.7-10 kΩ depending on the external
JTAG
circuitry) between VSS and the RTCK pin. To have them come up as GPIO
pins, do not connect a bias resistor, and ensure that any external
driver connected to Pin 26 (RTCK) is either driving high or is in
high-impedance state during Reset."
This seems to be in contradiction with section 20.8.2, which says:
"The Primary JTAG port can be selected for debugging only when DBGSEL
and RTCK pins are HIGH at reset (see Figure 66). If at least one of
the DBGSEL or RTCK lines is LOW at reset, JTAG will not be enabled and
can not be used for later debugging."
Should RTCK be pulled high or pulled low to enable the JTAG debugger pins?
--- In lpc2000@lpc2..., "ntfreak2000" <ntfreak2@h...> wrote:
> The TSRT pin is optional, the jtag cell reset can
be obtained by a TCK
> sequence. Anyway most of the manufactursr eg, philips. ST reset this
> when the SRST pin is asserted.
>
> This is what causes the problem of setting a hardware breakpoint at 0
> and doing a hard reset - does not work for a lot of devices.
>
> For some reason ARM9 devices very rarely reset the cell when SRST is
> asserted.
>
> TRST would normally be pulled up to enable debugging.
Reply by ntfreak2000●January 20, 20062006-01-20
The TSRT pin is optional, the jtag cell reset can be obtained by a TCK
sequence. Anyway most of the manufactursr eg, philips. ST reset this
when the SRST pin is asserted.
This is what causes the problem of setting a hardware breakpoint at 0
and doing a hard reset - does not work for a lot of devices.
For some reason ARM9 devices very rarely reset the cell when SRST is
asserted.
TRST would normally be pulled up to enable debugging.
Regards
Spen
--- In lpc2000@lpc2..., "Ed Schlunder" <zilym@y...> wrote: >
> That's what everyone else seems to do... The original wiggler clone
> schematic had it that way, the Olimex development boards seem to have
> both pins 1&2 tied to target VDD, etc.
>
> --- In lpc2000@lpc2..., "Soentgerath, Guido"
> <Guido.Soentgerath@s...> wrote:
>
> > just one question:
> > why do you connect pin 2 of the jtag connector with VDD ?
> >
> > From: lpc2000@lpc2... [mailto:lpc2000@lpc2...] On Behalf > > Of Ed Schlunder
> > Sent: Freitag, 20. Januar 2006 09:28
> > To: lpc2000@lpc2...
> > Subject: [lpc2000] Re: Building DIY wiggler w/74VHC14
> >
> >
> > I've been doing some more research on adding the nTRST signal to
the
> > DIY wiggler.
> >
> > http://www.macraigor.com/downloads/pinouts.pdf
> > http://sourceforge.net/tracker/index.php?funcail&aidy9377&group_id > > R603&atidF9852
> >
> > According to the above links, it looks like the genuine wiggler
> > actually already has support for driving the nTRST JTAG signal from
> > the parallel port's DATA4 pin.
> >
> > The existing DIY wiggler clone schematics have no connection of
DATA4
> > to nTRST like the real wiggler appearantly has. Could this be why
DIY
> > wiggler clones flake out on people?
> >
> > Here's the relevant section of ARM Application Note 31
> > (http://www.arm.com/pdfs/DAI0031C_using_eice.pdf):
> >
> > "nRESET is used to reset the processor core and put it into a
known
> > state, while nTRST is used to reset the TAP controller and the
> > EmbeddedICE macrocell, including the registers in the
> > breakpoint/watchpoint units. Both these resets must be applied
before
> > the device will function correctly."
> >
> > So, without any circuitry to drive nTRST, the TAP controller could
end
> > up in an unusable state where the host can not communicate with the
> > JTAG port. Doing a nRESET, which is all the DIY wiggler has control
> > over, would reset the processor core but never reset the TAP
> > controller used for JTAG debugging.
> >
> > I don't have a real wiggler, but given that the Macraigor pinouts
PDF
> > file shows the nTRST pin as being type "i" instead of type
"oc" like
> > the nRESET pin, I'm guessing that the nTRST signal should be
connected
> > to the DATA4 pin using a line driver instead of an inverting open
> > collector transistor circuit as used for the nRESET signal.
> >
> > I've updated my schematic diagram to include the proposed change
for
> > TRST:
> >
> > http://www.k9spud.com/jtag/
> >
> > --- In lpc2000@lpc2..., "derbaier" <dershu@s...>
wrote:
> > >
> > > --- In lpc2000@lpc2..., "Ed Schlunder"
<zilym@y...> wrote:
> > > >
> > > > Thank you for all the suggestions. I have put together an
initial
> > > > schematic diagram using 74VHC14 schmitt trigger inverters
and RC low > > > > pass filters (as suggested
here):
> > > >
> > > > http://www.k9spud.com/jtag/
> > > >
> > > > I'm not sure how to add additional signals like RTCK
and nTRST.
> > Won't
> > > > these kind of changes require software support on the PC to
be
> > useful?
> > > > My understanding was that the Macraigor software was not
open
> > source.
> > > > Where should these signals be connected to on the PC
side?
> > > >
> > > > Or are you just suggesting a jumper for the user to
manually switch > > by
> > > > hand?
> > > >
> > > > What is the nTRST signal useful for? I'm new to JTAG,
just trying to > > > > get my first ARM project
started.
> > > >
> > >
> > > Ed, your use of 'HC14 parts is exactly the same as ARM did
in their
> > > Application Note 31. IMHO, I think that you will find the RC
time
> > > constant of your filters to be much too long! With such large
> > > resistors, the input capacitance of the of the Schmitt triggers
will
> > > probably be plenty of low pass filtering! Also, if you want to save a > > > few parts, you can replace the
transistor inverter and it's assocoated > > > base resistors with one of your left
over 'HC14s with a series diode
> > > on it's output to convert it to an equivalent of an open
drain output. > > >
> > > A1. The signal connections on the PC side are fixed by the
closed
> > > source Macraigor software, so added enhancements to the hardeware will > > > not have Macraigor software support. In
any case, the Wiggler clock is > > > probably much too slow for RTCK to be
very useful unless the target
> > > ARM is being clocked at a much slower than normal speed. RTCK has been > > > VERY useful for very high speed JTAG
debuggers like TRACE32.
> > >
> > > A2. The nTRST signal is the JTAG TAP controller reset. The
other reset > > > signal is for the rest of the hardware.
In other words, ARM intended
> > > for them to be separately resetable, as they explain in section
12.3
> > > of Application Note 31.
>
Reply by Ed Schlunder●January 20, 20062006-01-20
That's what everyone else seems to do... The original wiggler clone
schematic had it that way, the Olimex development boards seem to have
both pins 1&2 tied to target VDD, etc.
--- In lpc2000@lpc2..., "Soentgerath, Guido"
<Guido.Soentgerath@s...> wrote:
> just one question:
> why do you connect pin 2 of the jtag connector with VDD ?
>
> From: lpc2000@lpc2... [mailto:lpc2000@lpc2...] On Behalf
> Of Ed Schlunder
> Sent: Freitag, 20. Januar 2006 09:28
> To: lpc2000@lpc2...
> Subject: [lpc2000] Re: Building DIY wiggler w/74VHC14
> I've been doing some more research on adding the nTRST signal to
the
> DIY wiggler.
>
> http://www.macraigor.com/downloads/pinouts.pdf
>
http://sourceforge.net/tracker/index.php?funcail&aidy9377&group_id
> R603&atidF9852
>
> According to the above links, it looks like the genuine wiggler
> actually already has support for driving the nTRST JTAG signal from
> the parallel port's DATA4 pin.
>
> The existing DIY wiggler clone schematics have no connection of DATA4
> to nTRST like the real wiggler appearantly has. Could this be why DIY
> wiggler clones flake out on people?
>
> Here's the relevant section of ARM Application Note 31
> (http://www.arm.com/pdfs/DAI0031C_using_eice.pdf):
>
> "nRESET is used to reset the processor core and put it into a known
> state, while nTRST is used to reset the TAP controller and the
> EmbeddedICE macrocell, including the registers in the
> breakpoint/watchpoint units. Both these resets must be applied before
> the device will function correctly."
>
> So, without any circuitry to drive nTRST, the TAP controller could end
> up in an unusable state where the host can not communicate with the
> JTAG port. Doing a nRESET, which is all the DIY wiggler has control
> over, would reset the processor core but never reset the TAP
> controller used for JTAG debugging.
>
> I don't have a real wiggler, but given that the Macraigor pinouts
PDF
> file shows the nTRST pin as being type "i" instead of type
"oc" like
> the nRESET pin, I'm guessing that the nTRST signal should be
connected
> to the DATA4 pin using a line driver instead of an inverting open
> collector transistor circuit as used for the nRESET signal.
>
> I've updated my schematic diagram to include the proposed change
for
> TRST:
>
> http://www.k9spud.com/jtag/
>
> --- In lpc2000@lpc2..., "derbaier" <dershu@s...> wrote:
> >
> > --- In lpc2000@lpc2..., "Ed Schlunder" <zilym@y...>
wrote:
> > >
> > > Thank you for all the suggestions. I have put together an
initial
> > > schematic diagram using 74VHC14 schmitt trigger inverters and RC
low
> > > pass filters (as suggested here):
> > >
> > > http://www.k9spud.com/jtag/
> > >
> > > I'm not sure how to add additional signals like RTCK and
nTRST.
> Won't
> > > these kind of changes require software support on the PC to be
> useful?
> > > My understanding was that the Macraigor software was not open
> source.
> > > Where should these signals be connected to on the PC side?
> > >
> > > Or are you just suggesting a jumper for the user to manually
switch
> by
> > > hand?
> > >
> > > What is the nTRST signal useful for? I'm new to JTAG, just
trying to
> > > get my first ARM project started.
> > >
> >
> > Ed, your use of 'HC14 parts is exactly the same as ARM did in
their
> > Application Note 31. IMHO, I think that you will find the RC time
> > constant of your filters to be much too long! With such large
> > resistors, the input capacitance of the of the Schmitt triggers
will
> > probably be plenty of low pass filtering! Also, if you want to save
a
> > few parts, you can replace the transistor inverter and it's
assocoated
> > base resistors with one of your left over 'HC14s with a series
diode
> > on it's output to convert it to an equivalent of an open drain
output.
> >
> > A1. The signal connections on the PC side are fixed by the closed
> > source Macraigor software, so added enhancements to the hardeware
will
> > not have Macraigor software support. In any case, the Wiggler clock
is
> > probably much too slow for RTCK to be very useful unless the target
> > ARM is being clocked at a much slower than normal speed. RTCK has
been
> > VERY useful for very high speed JTAG debuggers like TRACE32.
> >
> > A2. The nTRST signal is the JTAG TAP controller reset. The other
reset
> > signal is for the rest of the hardware. In other words, ARM
intended
> > for them to be separately resetable, as they explain in section
12.3
> > of Application Note 31.
Reply by Soentgerath, Guido●January 20, 20062006-01-20
Hello Ed,
just one question:
why did you connect pin 2 of the jtag connector with VDD ?
Thanks,
Guido
________________________________
From: lpc2000@lpc2... [mailto:lpc2000@lpc2...] On Behalf
Of Ed Schlunder
Sent: Freitag, 20. Januar 2006 09:28
To: lpc2000@lpc2...
Subject: [lpc2000] Re: Building DIY wiggler w/74VHC14
I've been doing some more research on adding the nTRST signal to the
DIY wiggler.
According to the above links, it looks like the genuine wiggler
actually already has support for driving the nTRST JTAG signal from
the parallel port's DATA4 pin.
The existing DIY wiggler clone schematics have no connection of DATA4
to nTRST like the real wiggler appearantly has. Could this be why DIY
wiggler clones flake out on people?
"nRESET is used to reset the processor core and put it into a known
state, while nTRST is used to reset the TAP controller and the
EmbeddedICE macrocell, including the registers in the
breakpoint/watchpoint units. Both these resets must be applied before
the device will function correctly."
So, without any circuitry to drive nTRST, the TAP controller could end
up in an unusable state where the host can not communicate with the
JTAG port. Doing a nRESET, which is all the DIY wiggler has control
over, would reset the processor core but never reset the TAP
controller used for JTAG debugging.
I don't have a real wiggler, but given that the Macraigor pinouts PDF
file shows the nTRST pin as being type "i" instead of type
"oc" like
the nRESET pin, I'm guessing that the nTRST signal should be connected
to the DATA4 pin using a line driver instead of an inverting open
collector transistor circuit as used for the nRESET signal.
I've updated my schematic diagram to include the proposed change for
TRST:
--- In lpc2000@lpc2..., "derbaier" <dershu@s...> wrote: >
> --- In lpc2000@lpc2..., "Ed Schlunder" <zilym@y...>
wrote:
> >
> > Thank you for all the suggestions. I have put together an initial
> > schematic diagram using 74VHC14 schmitt trigger inverters and RC
low
> > pass filters (as suggested here):
> >
> > http://www.k9spud.com/jtag/
> >
> > I'm not sure how to add additional signals like RTCK and
nTRST. Won't > > these kind of changes require software
support on the PC to be useful? > > My understanding was that the Macraigor
software was not open source. > > Where should these signals be connected to on
the PC side?
> >
> > Or are you just suggesting a jumper for the user to manually switch by > > hand?
> >
> > What is the nTRST signal useful for? I'm new to JTAG, just trying
to
> > get my first ARM project started.
> >
>
> Ed, your use of 'HC14 parts is exactly the same as ARM did in their
> Application Note 31. IMHO, I think that you will find the RC time
> constant of your filters to be much too long! With such large
> resistors, the input capacitance of the of the Schmitt triggers will
> probably be plenty of low pass filtering! Also, if you want to save a
> few parts, you can replace the transistor inverter and it's
assocoated
> base resistors with one of your left over 'HC14s with a series
diode
> on it's output to convert it to an equivalent of an open drain
output.
>
> A1. The signal connections on the PC side are fixed by the closed
> source Macraigor software, so added enhancements to the hardeware will
> not have Macraigor software support. In any case, the Wiggler clock is
> probably much too slow for RTCK to be very useful unless the target
> ARM is being clocked at a much slower than normal speed. RTCK has been
> VERY useful for very high speed JTAG debuggers like TRACE32.
>
> A2. The nTRST signal is the JTAG TAP controller reset. The other reset
> signal is for the rest of the hardware. In other words, ARM intended
> for them to be separately resetable, as they explain in section 12.3
> of Application Note 31.
________________________________
> .
________________________________
Reply by Soentgerath, Guido●January 20, 20062006-01-20
Hello Ed,
just one question:
why do you connect pin 2 of the jtag connector with VDD ?
Thanks,
Guido
________________________________
From: lpc2000@lpc2... [mailto:lpc2000@lpc2...] On Behalf
Of Ed Schlunder
Sent: Freitag, 20. Januar 2006 09:28
To: lpc2000@lpc2...
Subject: [lpc2000] Re: Building DIY wiggler w/74VHC14
I've been doing some more research on adding the nTRST signal to the
DIY wiggler.
According to the above links, it looks like the genuine wiggler
actually already has support for driving the nTRST JTAG signal from
the parallel port's DATA4 pin.
The existing DIY wiggler clone schematics have no connection of DATA4
to nTRST like the real wiggler appearantly has. Could this be why DIY
wiggler clones flake out on people?
"nRESET is used to reset the processor core and put it into a known
state, while nTRST is used to reset the TAP controller and the
EmbeddedICE macrocell, including the registers in the
breakpoint/watchpoint units. Both these resets must be applied before
the device will function correctly."
So, without any circuitry to drive nTRST, the TAP controller could end
up in an unusable state where the host can not communicate with the
JTAG port. Doing a nRESET, which is all the DIY wiggler has control
over, would reset the processor core but never reset the TAP
controller used for JTAG debugging.
I don't have a real wiggler, but given that the Macraigor pinouts PDF
file shows the nTRST pin as being type "i" instead of type
"oc" like
the nRESET pin, I'm guessing that the nTRST signal should be connected
to the DATA4 pin using a line driver instead of an inverting open
collector transistor circuit as used for the nRESET signal.
I've updated my schematic diagram to include the proposed change for
TRST:
--- In lpc2000@lpc2..., "derbaier" <dershu@s...> wrote: >
> --- In lpc2000@lpc2..., "Ed Schlunder" <zilym@y...>
wrote:
> >
> > Thank you for all the suggestions. I have put together an initial
> > schematic diagram using 74VHC14 schmitt trigger inverters and RC
low
> > pass filters (as suggested here):
> >
> > http://www.k9spud.com/jtag/
> >
> > I'm not sure how to add additional signals like RTCK and
nTRST. Won't > > these kind of changes require software
support on the PC to be useful? > > My understanding was that the Macraigor
software was not open source. > > Where should these signals be connected to on
the PC side?
> >
> > Or are you just suggesting a jumper for the user to manually switch by > > hand?
> >
> > What is the nTRST signal useful for? I'm new to JTAG, just trying
to
> > get my first ARM project started.
> >
>
> Ed, your use of 'HC14 parts is exactly the same as ARM did in their
> Application Note 31. IMHO, I think that you will find the RC time
> constant of your filters to be much too long! With such large
> resistors, the input capacitance of the of the Schmitt triggers will
> probably be plenty of low pass filtering! Also, if you want to save a
> few parts, you can replace the transistor inverter and it's
assocoated
> base resistors with one of your left over 'HC14s with a series
diode
> on it's output to convert it to an equivalent of an open drain
output.
>
> A1. The signal connections on the PC side are fixed by the closed
> source Macraigor software, so added enhancements to the hardeware will
> not have Macraigor software support. In any case, the Wiggler clock is
> probably much too slow for RTCK to be very useful unless the target
> ARM is being clocked at a much slower than normal speed. RTCK has been
> VERY useful for very high speed JTAG debuggers like TRACE32.
>
> A2. The nTRST signal is the JTAG TAP controller reset. The other reset
> signal is for the rest of the hardware. In other words, ARM intended
> for them to be separately resetable, as they explain in section 12.3
> of Application Note 31.
________________________________
> .
________________________________
Reply by Ed Schlunder●January 20, 20062006-01-20
I've been doing some more research on adding the nTRST signal to the
DIY wiggler.
According to the above links, it looks like the genuine wiggler
actually already has support for driving the nTRST JTAG signal from
the parallel port's DATA4 pin.
The existing DIY wiggler clone schematics have no connection of DATA4
to nTRST like the real wiggler appearantly has. Could this be why DIY
wiggler clones flake out on people?
"nRESET is used to reset the processor core and put it into a known
state, while nTRST is used to reset the TAP controller and the
EmbeddedICE macrocell, including the registers in the
breakpoint/watchpoint units. Both these resets must be applied before
the device will function correctly."
So, without any circuitry to drive nTRST, the TAP controller could end
up in an unusable state where the host can not communicate with the
JTAG port. Doing a nRESET, which is all the DIY wiggler has control
over, would reset the processor core but never reset the TAP
controller used for JTAG debugging.
I don't have a real wiggler, but given that the Macraigor pinouts PDF
file shows the nTRST pin as being type "i" instead of type
"oc" like
the nRESET pin, I'm guessing that the nTRST signal should be connected
to the DATA4 pin using a line driver instead of an inverting open
collector transistor circuit as used for the nRESET signal.
I've updated my schematic diagram to include the proposed change for
TRST:
--- In lpc2000@lpc2..., "derbaier" <dershu@s...> wrote: >
> --- In lpc2000@lpc2..., "Ed Schlunder" <zilym@y...>
wrote:
> >
> > Thank you for all the suggestions. I have put together an initial
> > schematic diagram using 74VHC14 schmitt trigger inverters and RC
low
> > pass filters (as suggested here):
> >
> > http://www.k9spud.com/jtag/
> >
> > I'm not sure how to add additional signals like RTCK and nTRST.
Won't
> > these kind of changes require software support on the PC to be
useful?
> > My understanding was that the Macraigor software was not open
source.
> > Where should these signals be connected to on the PC side?
> >
> > Or are you just suggesting a jumper for the user to manually switch
by
> > hand?
> >
> > What is the nTRST signal useful for? I'm new to JTAG, just trying
to
> > get my first ARM project started.
> >
>
> Ed, your use of 'HC14 parts is exactly the same as ARM did in their
> Application Note 31. IMHO, I think that you will find the RC time
> constant of your filters to be much too long! With such large
> resistors, the input capacitance of the of the Schmitt triggers will
> probably be plenty of low pass filtering! Also, if you want to save a
> few parts, you can replace the transistor inverter and it's
assocoated
> base resistors with one of your left over 'HC14s with a series
diode
> on it's output to convert it to an equivalent of an open drain
output.
>
> A1. The signal connections on the PC side are fixed by the closed
> source Macraigor software, so added enhancements to the hardeware will
> not have Macraigor software support. In any case, the Wiggler clock is
> probably much too slow for RTCK to be very useful unless the target
> ARM is being clocked at a much slower than normal speed. RTCK has been
> VERY useful for very high speed JTAG debuggers like TRACE32.
>
> A2. The nTRST signal is the JTAG TAP controller reset. The other reset
> signal is for the rest of the hardware. In other words, ARM intended
> for them to be separately resetable, as they explain in section 12.3
> of Application Note 31.
Reply by Bertrik Sikken●January 17, 20062006-01-17
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arie de Muynck wrote: > From: "Bertrik Sikken"
<bertrik@bert...>
>> Perhaps we can improve upon the existing designs and create
>> the ultimate low-cost ARM JTAG cable, yet keeping it simple.
>> Some ideas:
>> * provide proper current limiting for all lines
>> * add readback of the RTCK signal (return clock)
>> * add readback of the targets' VCC (like the Olimex clone does)
>
> Also:
>
> * use proper level shifting buffers or separate buffers for the LPT port
> side(5V logic) and the target side (target voltage).
> * use low-pass filters (RC) + schmidttrigger receivers on the LPT port
side.
> * series termination resistor on each driven line, to LPT and to target.
> * a (jumper selectable) nTRST drive, separate from the nRESET drive.
> * optional: a 1mA LED indicator on the target side VCC.
>
> The problems occur not just with building the thing - it's the
wiggler
> design itself that is a bit flakey, especially the lack of a noise
filter
> and schmidttrigger receiver on the CLK input at the LPT side. A
100...400
> nsec RC filter should do it while still allowing up to 1 MHz clocking
(above
> LPT port speed levels). If this is not present, long LPT cables or
improper
> grounding will cause glitches that upset the JTAG state machine.
>
> I fail to see the actual use of the RTCK signal - is this to be tested by
SW
> on the LPT status bits? Which CPU is so slow that this would make a
> difference?
Well, if there are spare pins on the parallel port, unconnected pins
on the JTAG connector and unused buffers in the line driver, then
why _not_ just connect them?
We could use the RTCK pin to check if JTAG is echoing TCK properly
or not. Or it could be used to check if RTCK is indeed pulled-down
during reset (required for the LPC2148 for example).
I don't know if the RTCK can in practice be used to actually check
synchronisation with TCK, or how slow a CPU needs to be for that.
Ofcourse, if the goal is just to build an exact wiggler clone,
there's no need for it.
Regards,
Bertrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
--- In lpc2000@lpc2..., "Ed Schlunder" <zilym@y...>
wrote: >
> Thank you for all the suggestions. I have put together an initial
> schematic diagram using 74VHC14 schmitt trigger inverters and RC low
> pass filters (as suggested here):
>
> http://www.k9spud.com/jtag/
>
> I'm not sure how to add additional signals like RTCK and nTRST.
Won't
> these kind of changes require software support on the PC to be useful?
> My understanding was that the Macraigor software was not open source.
> Where should these signals be connected to on the PC side?
>
> Or are you just suggesting a jumper for the user to manually switch by
> hand?
>
> What is the nTRST signal useful for? I'm new to JTAG, just trying
to
> get my first ARM project started.
>
Ed, your use of 'HC14 parts is exactly the same as ARM did in their
Application Note 31. IMHO, I think that you will find the RC time
constant of your filters to be much too long! With such large
resistors, the input capacitance of the of the Schmitt triggers will
probably be plenty of low pass filtering! Also, if you want to save a
few parts, you can replace the transistor inverter and it's assocoated
base resistors with one of your left over 'HC14s with a series diode
on it's output to convert it to an equivalent of an open drain output.
A1. The signal connections on the PC side are fixed by the closed
source Macraigor software, so added enhancements to the hardeware will
not have Macraigor software support. In any case, the Wiggler clock is
probably much too slow for RTCK to be very useful unless the target
ARM is being clocked at a much slower than normal speed. RTCK has been
VERY useful for very high speed JTAG debuggers like TRACE32.
A2. The nTRST signal is the JTAG TAP controller reset. The other reset
signal is for the rest of the hardware. In other words, ARM intended
for them to be separately resetable, as they explain in section 12.3
of Application Note 31.
Regards,
-- Dave
Reply by Leon Heller●January 17, 20062006-01-17
----- Original Message -----
From: "Stephen Pelc" <stephen@step...>
To: <lpc2000@lpc2...>
Sent: Tuesday, January 17, 2006 10:55 AM
Subject: [lpc2000] Building DIY wiggler w/74VHC08
>> From: "Leon Heller"
<leon.heller@leon...>
>
>> I think that is probably the case, contrary to what I said
>> earlier. Ground bounce due to poor construction techniques may be
>> one reason why some people have problems getting it to work
>> reliably.
>
> Some PC printer ports generate fast (<10ns) spikes of up to 1
> volt amplitude on some pins. They can be very difficult to
> remove, and will often trigger buffers that have TTL threshold
> levels. Most printer ports now run at about 3v and if the device
> is powered through the printer port, it is probably operating
> way outside its datasheet specs.
