This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to detect presence of component in Embedded system?

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 of each of the components mentioned above. If any of the component is removed from the system or it has failed to function then the AT89c52 need to detect the failed or removed component and the whole system need to go to fail safe mode.

Can anyone help me with this issue.
Raghu

Parents
  • I think you need to read up a bit about designing reliable, self-testing and/or redundant hardware.

    The only thing your uC knows is if it's individual signals are high or low. It is up to you to decide if the combination of signals are reasonable or not.

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

    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.

    Remember that buffer chips are most likely to fail on the external signals, since it's the external signals that may suffer unconditioned signals.

    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.

    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.

    By the way: removed components? Are people expected to steal components from a live system or???

Reply
  • I think you need to read up a bit about designing reliable, self-testing and/or redundant hardware.

    The only thing your uC knows is if it's individual signals are high or low. It is up to you to decide if the combination of signals are reasonable or not.

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

    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.

    Remember that buffer chips are most likely to fail on the external signals, since it's the external signals that may suffer unconditioned signals.

    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.

    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.

    By the way: removed components? Are people expected to steal components from a live system or???

Children
  • "Loopback" is a technique where data sent out from an output is "looped" back to an input - so that the processor can verify that the complete path is working.

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

  • Loopback is very good to have, and to make use of. Alas, it often isn'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.

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

    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.