<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>How to detect presence of component in Embedded system?</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/21568/how-to-detect-presence-of-component-in-embedded-system</link><description> 
Hi, 
I am working on a safety critical system project for railways and I
am using AT89C52 micro controller. 

 
I use a number of buffers (74ls373), decoders (74ls138) ,
multiplexers(74ls157) etc. During self test of the I need to check
the presence</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: How to detect presence of component in Embedded system?</title><link>https://community.arm.com/thread/50619?ContentTypeID=1</link><pubDate>Fri, 13 Apr 2007 12:33:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:90062846-87aa-4ef8-b352-0d778214f9f2</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&lt;b&gt;a safety critical system project&lt;/b&gt; ... I use a number of
buffers (74ls373), decoders (74ls138) , multiplexers(74ls157&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
You are making a basic error, the issue of failure detect is, of
course important, but &lt;b&gt;failure avoidance&lt;/b&gt; is far more
important.&lt;br /&gt;
More components equals failure more likely, more solder joints equals
failure more likely.&lt;br /&gt;
Get rid of the discrete chips, use an 8 port uC (e.g. SILabs
8051f12x/f13x) and (if needed) a FPGA/CPLD.&lt;/p&gt;

&lt;p&gt;
With such a scheme you get far better reliability and, as a bonus,
for the uC ports - they are always there; and, for the CPLD/FPGA
implememnting loopback is a breeze.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: How to detect presence of component in Embedded system?</title><link>https://community.arm.com/thread/99107?ContentTypeID=1</link><pubDate>Fri, 13 Apr 2007 11:21:39 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:75ea8ea0-9bc6-4bc9-8f6e-1710fbd605f1</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Loopback is very good to have, and to make use of. Alas, it often
isn&amp;#39;t enough. Many communication chips that have loopback support
only have internal loopback, because the receive and transmit signals
are on separate external pins. All logic in the chip is tested, but
no actual hw pins are used.&lt;/p&gt;

&lt;p&gt;
External loopback requires that the interface is using the same
signal line for both receive or transmit, or that the communications
chip can listen to it&amp;#39;s own physical transmit signals. Unless the
chip does this by use of two bond wires, the signal input will not
notice if the bond wire for the output pin is broken.&lt;/p&gt;

&lt;p&gt;
If external loopback is implemented using external hw, then it is
hard to know if the external hw is working ok in non-loopback
mode.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: How to detect presence of component in Embedded system?</title><link>https://community.arm.com/thread/88284?ContentTypeID=1</link><pubDate>Fri, 13 Apr 2007 08:49:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:94fbbe7b-ea79-4933-889b-56d6a1b2e0fc</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;Loopback&amp;quot; is a technique where data sent out from an output is
&amp;quot;looped&amp;quot; back to an input - so that the processor can verify that the
complete path is working.&lt;/p&gt;

&lt;p&gt;
As well as implementing the loopback path, You also need to design
the test signals carefully to ensure that they really do confirm that
everything is working and, preferably, can also precisely identify
the nature of any fault...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: How to detect presence of component in Embedded system?</title><link>https://community.arm.com/thread/50623?ContentTypeID=1</link><pubDate>Thu, 12 Apr 2007 05:45:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c6d2d0f0-121d-4c1c-a52b-86e5111d9ba3</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
I think you need to read up a bit about designing reliable,
self-testing and/or redundant hardware.&lt;/p&gt;

&lt;p&gt;
The only thing your uC knows is if it&amp;#39;s individual signals are
high or low. It is up to you to decide if the combination of signals
are reasonable or not.&lt;/p&gt;

&lt;p&gt;
To make your hw testable, you need to look into programmable logic
with support for boundary scan, to allow you to serially read out the
state of all signals (i.e. not just the signals between the chip and
your uC, but all the other signals too).&lt;/p&gt;

&lt;p&gt;
You may also use shift registers to scan signal states in the
system. Of course, it is hard to detect if an input is broken and
always reading a high or a low, if the actual signal on that pin is
normally expected to have that specific state. Because of this,
serial communication and timed data is advantageous. You will then
know if you can get data, or if a signal has locked up.&lt;/p&gt;

&lt;p&gt;
Remember that buffer chips are most likely to fail on the external
signals, since it&amp;#39;s the external signals that may suffer
unconditioned signals.&lt;/p&gt;

&lt;p&gt;
In some situations, it is also advantageous to add extra output
signals, to let your uC force changes to mux or decoder chips, and
then use serial detection to verify that your forced changes can be
detected.&lt;/p&gt;

&lt;p&gt;
If the system controls critical functions, then you want the
hardware to be able to stop dangerous processing if the uC stops
responding, or the board detects invalid sensor data. One more reason
for serial communication - it is easy to build hw watchdogs.&lt;/p&gt;

&lt;p&gt;
By the way: removed components? Are people expected to steal
components from a live system or???&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>