C
Charles
Guest
Has anyone ever used this method for field troubleshooting?
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
M
Michael A. Terrell
Guest
Charles wrote:
How do you propose using the programming interface to troubleshoot
something? Are you going to write custom software and reprogram the
processor? What software and interface do you have, and is it
appropriate for the CPU involved? I programmed various embedded
controller boards for four years with JTAG, but there was no way to
troubleshoot the board from that port. Boundary scan is for testing the
CPU, not the rest of the board.
--
You can't fix stupid. You can't even put a Band-Aid on it, because it's
Teflon coated.
Has anyone ever used this method for field troubleshooting?
How do you propose using the programming interface to troubleshoot
something? Are you going to write custom software and reprogram the
processor? What software and interface do you have, and is it
appropriate for the CPU involved? I programmed various embedded
controller boards for four years with JTAG, but there was no way to
troubleshoot the board from that port. Boundary scan is for testing the
CPU, not the rest of the board.
--
You can't fix stupid. You can't even put a Band-Aid on it, because it's
Teflon coated.
C
Charles
Guest
"Michael A. Terrell" wrote in message
news:Xqednch4f4U7OufQnZ2dnUVZ_jCdnZ2d@earthlink.com...
Charles wrote:
How do you propose using the programming interface to troubleshoot
something? Are you going to write custom software and reprogram the
processor? What software and interface do you have, and is it
appropriate for the CPU involved? I programmed various embedded
controller boards for four years with JTAG, but there was no way to
troubleshoot the board from that port. Boundary scan is for testing the
CPU, not the rest of the board.
Not proposing anything. Asking a question. Not a good idea here, these
days.
news:Xqednch4f4U7OufQnZ2dnUVZ_jCdnZ2d@earthlink.com...
Charles wrote:
Has anyone ever used this method for field troubleshooting?
How do you propose using the programming interface to troubleshoot
something? Are you going to write custom software and reprogram the
processor? What software and interface do you have, and is it
appropriate for the CPU involved? I programmed various embedded
controller boards for four years with JTAG, but there was no way to
troubleshoot the board from that port. Boundary scan is for testing the
CPU, not the rest of the board.
Not proposing anything. Asking a question. Not a good idea here, these
days.
D
Dave Platt
Guest
In article <Xqednch4f4U7OufQnZ2dnUVZ_jCdnZ2d@earthlink.com>,
Michael A. Terrell <mike.terrell@earthlink.net> wrote:
JTAG was originally designed to be a board-checkout feature! It
allows you to chain together any number of digital devices and probe
them, read their input pins, write values to their output pins, etc.
As the Great Source of Dubious Knowledge (Wikipedia) states, "It was
initially devised for testing printed circuit boards using boundary
scan and is still widely used for this application."
Its use as a method of programming the on-board (or external) flash
memory for a microcontroller is only one of its functions... a very
common one but not necessarily its most important.
With many processors, it's possible to access the on-chip debug-and-
trace engine - stop the processor, single-step it, read out the
registers or modify them, etc.
It's very much up to a board designer (and to the designers of the
chips being used) to decide how much functionality is going to be
exposed via JTAG. On some boards, accessing/programming the flash may
be all that's possible. On others, you may be able to individually
interrogate and exercise every single I/O pin on every outward-facing
chip on the whole board.
--
Dave Platt <dplatt@radagast.org> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Michael A. Terrell <mike.terrell@earthlink.net> wrote:
Hunh?How do you propose using the programming interface to troubleshoot
something? Are you going to write custom software and reprogram the
processor? What software and interface do you have, and is it
appropriate for the CPU involved? I programmed various embedded
controller boards for four years with JTAG, but there was no way to
troubleshoot the board from that port. Boundary scan is for testing the
CPU, not the rest of the board.
JTAG was originally designed to be a board-checkout feature! It
allows you to chain together any number of digital devices and probe
them, read their input pins, write values to their output pins, etc.
As the Great Source of Dubious Knowledge (Wikipedia) states, "It was
initially devised for testing printed circuit boards using boundary
scan and is still widely used for this application."
Its use as a method of programming the on-board (or external) flash
memory for a microcontroller is only one of its functions... a very
common one but not necessarily its most important.
With many processors, it's possible to access the on-chip debug-and-
trace engine - stop the processor, single-step it, read out the
registers or modify them, etc.
It's very much up to a board designer (and to the designers of the
chips being used) to decide how much functionality is going to be
exposed via JTAG. On some boards, accessing/programming the flash may
be all that's possible. On others, you may be able to individually
interrogate and exercise every single I/O pin on every outward-facing
chip on the whole board.
--
Dave Platt <dplatt@radagast.org> AE6EO
Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
D
D Yuniskis
Guest
HI Charles,
On 3/11/2011 3:21 PM, Charles wrote:
this way. You would need far too much information about
the devices involved, their interconnects, etc.
When *designing* a product, careful consideration to the
JTAG abilities of the device(s) you use can help bring *up*
a system (virgin hardware) by giving you control over
nodes that would otherwise be difficult to manipulate.
Many MCU's also use JTAG to program onboard memory and/or
a crude software debugging interface.
But, unless the manufacturer has specifically designed a tool
that hides all of this detail from you and reduces it to
a set of indicators (or, perhaps, an interface to software
running on a laptop), chances are, it won't be of much
practical use (though it is often used to "hack" or
"repurpose" existing devices despite the manufacturer's
original intent).
Some products will bring JTAG pins out to an (undocumented)
connector. Or, they'll be microprobed in production (to
save the cost of the connector :> ). Similarly, many products
have "free" serial ports that are routed (and often have
interesting capabilities! :> )
But, JTAG isn't as nice and semi-standardized as OBD, OBD-II,
etc. for automobiles... too many variables to account for.
Sorry.
On 3/11/2011 3:21 PM, Charles wrote:
I doubt you will find anyone using a *raw* JTAG i/f inHas anyone ever used this method for field troubleshooting?
this way. You would need far too much information about
the devices involved, their interconnects, etc.
When *designing* a product, careful consideration to the
JTAG abilities of the device(s) you use can help bring *up*
a system (virgin hardware) by giving you control over
nodes that would otherwise be difficult to manipulate.
Many MCU's also use JTAG to program onboard memory and/or
a crude software debugging interface.
But, unless the manufacturer has specifically designed a tool
that hides all of this detail from you and reduces it to
a set of indicators (or, perhaps, an interface to software
running on a laptop), chances are, it won't be of much
practical use (though it is often used to "hack" or
"repurpose" existing devices despite the manufacturer's
original intent).
Some products will bring JTAG pins out to an (undocumented)
connector. Or, they'll be microprobed in production (to
save the cost of the connector :> ). Similarly, many products
have "free" serial ports that are routed (and often have
interesting capabilities! :> )
But, JTAG isn't as nice and semi-standardized as OBD, OBD-II,
etc. for automobiles... too many variables to account for.
Sorry.
M
Michael A. Terrell
Guest
Dave Platt wrote:
How is it going to help troubleshoot the analog portions of a board?
Or a faulty on board voltage regulator? Have you personally ever used
it to fix a bad circuit board?
--
You can't fix stupid. You can't even put a Band-Aid on it, because it's
Teflon coated.
In article <Xqednch4f4U7OufQnZ2dnUVZ_jCdnZ2d@earthlink.com>,
Michael A. Terrell <mike.terrell@earthlink.net> wrote:
How do you propose using the programming interface to troubleshoot
something? Are you going to write custom software and reprogram the
processor? What software and interface do you have, and is it
appropriate for the CPU involved? I programmed various embedded
controller boards for four years with JTAG, but there was no way to
troubleshoot the board from that port. Boundary scan is for testing the
CPU, not the rest of the board.
Hunh?
JTAG was originally designed to be a board-checkout feature! It
allows you to chain together any number of digital devices and probe
them, read their input pins, write values to their output pins, etc.
As the Great Source of Dubious Knowledge (Wikipedia) states, "It was
initially devised for testing printed circuit boards using boundary
scan and is still widely used for this application."
Its use as a method of programming the on-board (or external) flash
memory for a microcontroller is only one of its functions... a very
common one but not necessarily its most important.
With many processors, it's possible to access the on-chip debug-and-
trace engine - stop the processor, single-step it, read out the
registers or modify them, etc.
It's very much up to a board designer (and to the designers of the
chips being used) to decide how much functionality is going to be
exposed via JTAG. On some boards, accessing/programming the flash may
be all that's possible. On others, you may be able to individually
interrogate and exercise every single I/O pin on every outward-facing
chip on the whole board.
How is it going to help troubleshoot the analog portions of a board?
Or a faulty on board voltage regulator? Have you personally ever used
it to fix a bad circuit board?
--
You can't fix stupid. You can't even put a Band-Aid on it, because it's
Teflon coated.
C
Charles
Guest
"Charles" wrote in message news:ile792$ksh$1@news.eternal-september.org...
Has anyone ever used this method for field troubleshooting?
Hey Dave Platt and D Yuniskis ... thanks!
Seems that the promise of JTAG for field service has fallen by the wayside,
for troubleshooting and repair at least. It is used for firmware upgrades.
Economics rule!
Has anyone ever used this method for field troubleshooting?
Hey Dave Platt and D Yuniskis ... thanks!
Seems that the promise of JTAG for field service has fallen by the wayside,
for troubleshooting and repair at least. It is used for firmware upgrades.
Economics rule!
M
Michael A. Terrell
Guest
Charles wrote:
I see that no one bit on your duplicate post on
news:sci.electronics.design
Most designs don't have enough spare flash for any diagnostics. It
isn't worth the trouble for anything outside a factory where an
automated test fixture can test the entire board without being
reprogrammed. Not what you want to hear, but it's the truth. The
'boundary' stops at the I/O pins where it was intended to. It was a way
to test a complex processor with limited tools, not an entire board.
--
You can't fix stupid. You can't even put a Band-Aid on it, because it's
Teflon coated.
"Charles" wrote in message news:ile792$ksh$1@news.eternal-september.org...
Has anyone ever used this method for field troubleshooting?
Hey Dave Platt and D Yuniskis ... thanks!
Seems that the promise of JTAG for field service has fallen by the wayside,
for troubleshooting and repair at least. It is used for firmware upgrades.
Economics rule!
I see that no one bit on your duplicate post on
news:sci.electronics.design
Most designs don't have enough spare flash for any diagnostics. It
isn't worth the trouble for anything outside a factory where an
automated test fixture can test the entire board without being
reprogrammed. Not what you want to hear, but it's the truth. The
'boundary' stops at the I/O pins where it was intended to. It was a way
to test a complex processor with limited tools, not an entire board.
--
You can't fix stupid. You can't even put a Band-Aid on it, because it's
Teflon coated.
C
Charles
Guest
I see that no one bit on your duplicate post on
news:sci.electronics.design Yup, not a single reply. Not surprised.
Most designs don't have enough spare flash for any diagnostics. It
isn't worth the trouble for anything outside a factory where an
automated test fixture can test the entire board without being
reprogrammed. Not what you want to hear, but it's the truth. The
'boundary' stops at the I/O pins where it was intended to. It was a way
to test a complex processor with limited tools, not an entire board.
I am guessing that the up-front costs for field service cannot be justified
(sold to management). Other than flash upgrades, it appears to be an
unfulfilled promise (pipe dream?) as far as field service is concerned.
Thanks.
news:sci.electronics.design Yup, not a single reply. Not surprised.
Most designs don't have enough spare flash for any diagnostics. It
isn't worth the trouble for anything outside a factory where an
automated test fixture can test the entire board without being
reprogrammed. Not what you want to hear, but it's the truth. The
'boundary' stops at the I/O pins where it was intended to. It was a way
to test a complex processor with limited tools, not an entire board.
I am guessing that the up-front costs for field service cannot be justified
(sold to management). Other than flash upgrades, it appears to be an
unfulfilled promise (pipe dream?) as far as field service is concerned.
Thanks.