A self-testing GPIO

General purpose input-output (GPIO) pins are the simplest peripherals.

The link to an object under control (OUC) may become inadvertently unreliable due to many reasons: a loss of contact, short circuit, temperature stress or a vapor condensate on the components. Sometimes a better link can be established with the popular bridge chip by simply exploring the possibilities provided by the chip itself.

Wow the engineering world with your unique design: Design Ideas Submission Guide

The bridge, such as NXP’s SC18IM700, usually provides a certain amount of GPIOs, which are handy to implement a test. These GPIOs preserve all their functionality and can be used as usual after the test.

To make the test possible, the chip must have more than one GPIO. This way, they can be paired, bringing the opportunity for the members of the pair to poll each other.

Since the activity of the GPIO during test may harm the regular functions of the OUC, one of the GPIO pins can be chosen to temporary prohibit these functions. Very often, when this object is quite inertial, this prohibition may be omitted.

Figure 1 shows how the idea can be implemented in the case of the SC18IM700 UART-I2C bridge.

Figure 1: Self-testing GPIO using the SC18IM70pytho0 UART-I2C bridge.

The values of resistors R1…R4 must be large enough not to lead to an unacceptably large current; on the other hand, they should provide sufficient voltage for the logic “1” on the input. The values shown on Figure 1 are good for the most applications but may need to be adjusted.

Some difficulties may arise only with a quasi-bidirectional output configuration, since in this configuration it is weakly driven when the port outputs a logic HIGH. The problem may occur when the resistance of the corresponding OUC input is too low.

If the data rate of the UART output is too high for a proper charging of the OUC-related capacitance during the test, it can be decreased or, the corresponding values of the resistors can be lessened.

The sketch of the Python subroutine follows:

PortConf1=0x02
PortConf2=0x03

def selfTest():
data=0b10011001
bridge.writeRegister(PortConf1, data) #PortConfig1

data=0b10100101
bridge.writeRegister(PortConf2, data) #PortConfig2

#— write 1
cc=0b11001100
bridge.writeGPIO(cc)

aa=bridge.readGPIO() # 0b11111111
if aa != 0b11111111 : return False # check

#—- write 0
cc=0b00000000
bridge.writeGPIO(cc)

aa=bridge.readGPIO()
if aa != 0b00000000 : return False # check

# partners swap
data=0b01100110
bridge.writeRegister(PortConf1, data) #PortConfig1

data=0b01011010
bridge.writeRegister(PortConf2, data) #PortConfig2

#—write 1
cc=0b00110011
bridge.writeGPIO(cc)

aa=bridge.readGPIO()
if aa != 0b11111111 : return False # check

#—- write 0
cc=0b00000000
bridge.writeGPIO(cc)

aa=bridge.readGPIO()
if aa != 0b00000000 : return False # check

# check quasy-bidirect
data=0b01000100
bridge.writeRegister(PortConf1, data) #PortConfig1

data=0b01010000
bridge.writeRegister(PortConf2, data) #PortConfig2

#—write 1
cc=0b00110011
bridge.writeGPIO(cc)

aa=bridge.readGPIO()
if aa != 0b11111111 : return False # check

#—- write 0
cc=0b00000000
bridge.writeGPIO(cc)

aa=bridge.readGPIO()
if aa != 0b00000000 : return False # check
return True

—Peter Demchenko studied math at the University of Vilnius and has worked in software development.

<!–
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>

The post A self-testing GPIO appeared first on EDN.

Become a member

Become a member

Become a subscriber

Become a sponsor