This article has been accepted for publication in IEEE Access.

This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

Date of publication xxxx 00, 0000, date of current version xxxx 00, 0000.
Digital Object Identifier 10.1109/ACCESS.2017.Doi Number

Fault Analysis and Mitigation Techniques

of the I2C Bus for Nanosatellite Missions
Amina Albalooshi1, Abdul-Halim Jallad2,3, Member, IEEE, and Prashanth Marpu4, Senior
Member, IEEE
1
National Space Science Agency, Bahrain.
2
Department of Electrical Engineering, United Arab Emirates University, Al Ain, UAE.
3
National Space Science and Technology Center, United Arab Emirates University, Al Ain, UAE.
4
Group 42, Abu Dhabi, UAE

Corresponding author: Abdul-Halim Jallad (e-mail: [email protected]).

ABSTRACT Despite the reliability concerns that are associated with the I2C bus, it is still one of the most
popular on-board data busses to be used in nanosatellite missions. This paper provides a detailed fault analysis
for the I2C bus in the context of nanosatellite missions, and consequently investigates and proposes potential
mitigation techniques. The failure of the I2C bus is a risk that most CubeSat missions has to deal with, as the
related bus failures can cause some catastrophic failures. Therefore, this study analyzes the I2C bus
characteristics, the hardware and software requirements, and the key factors leading to I2C bus failure. By
conducting experimental testing using the appropriate hardware and software to construct a comprehensive
list of I2C bus requirements, characteristics, and failures. Based on the experimental testing possible
mitigation approaches are proposed and finally a qualitative risk analysis is delivered to measure the impact
of the methods on the overall mission success. The study shows high influence of the I2C bus on the CubeSat
health and mission success, thus emphasizing on the importance of design considerations to reduce missions’
risk level, as well as counting for runtime failures that can occur during mission operation.

INDEX TERMS Nanosatellites, CubeSats, I2C Bus, Reliability, Fault Mitigation.

I. INTRODUCTION This paper deals with the on-board data busses commonly
In the late 1990s Polytechnic State University and Stanford deployed on modern CubeSat missions.
University introduced a new concept of satellites, that are built The I2C bus is one of the most commonly employed data
according to the CubeSat Standard Specification. The busses on-board CubeSat missions [2]. I2C Bus failures are
specifications included the definition of various mechanical difficult to detect and resolve making it essential for CubeSat
and electrical standards that have helped in the rapid spread of developers to account for them during the design phase.
CubeSats around the world. The concept of CubeSat is to have Several previous missions with catastrophic failures
a class-based design with standard unit, one unit is referred to hypothesized that the mission failure was due to the I2C bus,
as 1U and has dimensions of 10x10x10 cm and not to weigh MYSat-1 CubeSat launched by Khalifa University [20], lost
more than 1.33 kg. However, the design of CubeSats is not communication with the ground station for more than a year,
constrained by one unit, as CubeSat designers have the choice with a most likely cause of failure to be due to a I2C bus-
of building bigger CubeSats that consist of multiple units 2U, related failure. Another satellite, MeznSat, also faced in-orbit
3U, 6U, etc. This concept made it easier and less costly issues that have been analyzed to be related to the I2C bus [21].
to build satellites, and hence enabled universities and Researchers proposed various approaches to increase I2C
educational institutions to join the field alongside bus reliability and robustness against different failures,
governments, military, space agencies and huge commercial applying either hardware or software changes to the original
firms [1, 14]. I2C bus design. Previous work on I2C reliability involving
Satellite reliability is an extremely critical aspect in the hardware enhancements included the addition of hardware to
overall design of any space mission; since it has direct impact control devices’ availability on the bus [11], or to avoid
on the mission success, partial mission success or even address conflicts [8]. Also, previous work has been reported
catastrophic failures that lead to CubeSat loss. Several on adding a hardware circuit to isolate the I2C nodes from the
missions have been reported to have had such failures such as: bus in the event of device failure [16] [22]. This approach
CP4, Delfi-c3, Delfi-n3xt. Thus, every aspect of the CubeSat works on the prevention of having the faulty nodes holding the
mission design must be carefully considered for reliability. bus lines permanently and hence causing the whole bus to

VOLUME XX, 2017 1

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

malfunction. On the other hand, software modifications were SDA line is a bidirectional line which carries the data between
implemented to avoid I2C bus lockups, and to alert I2C master the master and slaves, SCL line is a one directional line which
of the occurred fault [12]. carries the clock signal from the master device [5]. The two
In this paper, we present an analysis of the suspected faults wires are connected to a high voltage through pullup resistors,
and failures of the I2C data bus in CubeSat projects. In the which determine the bus speed, and the typical I2C bus pullup
analysis, we list the expected I2C data bus threats over resistor values are 2 k Ω for the fast mode with speed of 400
CubeSats’ mission success, where each of the threats is further kbps and 10 k Ω normal mode with speed of 100 kbps speeds,
analyzed by experimental testing to detect the root cause of respectively [6]. The data transmission on the I2C bus is
fault or failure. The goal of this study is then to propose controlled by start and stop conditions sent by the master, both
mitigation methods to terminate those threats or reduce their start and stop signals can be identified by the change of the
impact on the missions’ success. SDA line while the SCL line is held high, start condition is a
The literature lacks a comprehensive review and practical falling edge of a pulse on the SDA line and stop condition is
analysis of the failure risks associated with the I2C bus, the rising edge of a pulse on the SDA line.
particularly in relation to its use in nanosatellite space
missions. This has been noticed by researchers as reported in
some recent publications [22]. The contribution of this paper
is that it precisely presents and analyzes possible failure risks
of the I2C bus and mitigation methods of these failures. We
emulate in the lab the identified risks and their consequences
on the bus and hence on the mission. We identify the level of
each of the identified risks and propose and evaluate the
mitigation techniques for each of these risks. This will enable
researchers and designers of nanosatellite missions to improve
the reliability of their missions, given that the I2C bus
FIGURE 1. The Top-level Architecture of the I2C Bus
reliability is central to the success of some of those missions.
To the best of our knowledge, such a practical risk analysis
The I2C protocol defines a unique address for each slave
study has not been reported previously in the literature.
with a size of 7-bits. The master device is the only peripheral
The remainder of this paper is organized as follows: Section
that does not require an address for it being the only initiator
II provides a brief explanation about the I2C bus, Section III
of all transactions. The protocol divides the data transmitted
provides the related work conducted by previous researchers,
on the SDA line to bytes; the first is reserved for the slave
Section IV presents the methodology used to conduct this
address, second for the register address and the last of the data.
study, Section V discusses the results attained from this
All transactions on the bus start with a start signal and for each
research, Section VI presents the practical implication for
of the sent bytes the master awaits an acknowledgement from
implementing the I2C bus in CubeSats, and the final section
the slave it is communicating with. After successful
provides the conclusions.
establishment of communication, the master or slave starts
II. The Inter-Integrated Circuit (I2C) Bus
sending the data bytes. Finally, the master sends a stop
condition to terminate the session.
A. Overview of the Bus The simplicity of the I2C bus makes it susceptible to faults
Inter-Integrated Circuit (I2C) is a data bus used to handle data and failures especially when implemented without shielding in
transmissions between peripherals, originally designed for the harsh space environment as it is vulnerable to failures due
short distance communications within a single device. The I2C to exposure to radiation. Radiation plays a role is causing bit-
bus has gained its popularity due to its simplicity and low cost flips on the I2C bus and I2C devices, which can lead to
[3]. The I2C bus allows communication between low-speed corruption in the operating system, program, or
peripheral ICs to processors and microcontrollers in short microcontroller pointer, eventually leading to bus lockups [3,
distances [2], enabling a variety of different topologies such as 7]. Bus lockup is the state where the I2C master loses its
single master to single/multi slaves or multi masters to multi connectivity with all slaves and the data transmission on the
slaves. Manufacturers prefer I2C over other data buses for its bus is blocked. Bus lockups are very common I2C failure and
low manufacturing cost, prioritizing the cost of the data bus occur mainly due to the simplicity of the bus design especially
over the speed [4]. for not implementing any data integrity check nor failure
The I2C protocol adopts a simple bidirectional recovery [3], making it a single point of failure to CubeSat
communication concept as shown in Figure 1, in which only missions [7]. Additionally, transient faults that occur in the
two wires are required for connecting all devices on the bus I2C cores such as a bitflip in registers, and missing
[5]. The two wires are Serial Data Line (SDA) and Serial acknowledgements can lead to bus lockups as well. Missing
Clock Line (SCL), each carrying different type of data; the acknowledgements on the I2C bus occur for various reasons,
those include timing delay between SCL and SDA lines,
2

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

missing or unexpected SCL pulse, incomplete 8-bit block, or CubeSat that failed due to the I2C bus failure [18], Delfi-c3 of
missing bytes [8]. TU Delft experienced high error-rates and bus lockups, and
The key differences that make the I2C bus more prone to Delfi-n2Xt failure is related to the experimental transponder
failure in comparison to the other deployed data buses in activation and assumed to be the malfunctioning of the I2C
CubeSat missions, namely SPI and RS-232. Firstly, all buffer [19]. Several other CubeSats have also been reported
communication between peripherals occurs on the SDA line the I2C bus to be the known source of mission failures [15-
not allowing protocol handshaking on a dedicated line. 17].
Secondly, Connecting high number of nodes on the same data
bus unlike other protocols. The prior two characteristics III. Related Work
increase the probability of having errors that can lead to faults The I2C bus failure detection and mitigation have attracted
or failures such as errors resulting from microcontroller state- many researchers to investigate the topic due to its popularity
machine which are then passed to the bus [2]. Also, the lack and high vulnerability to failures. Researchers considered
of component isolation on the I2C bus which allows faulty different approaches to perform integration test to test
devices to fail the whole bus [9]. CubeSats immunity to failure by developing fault injection
tool, the main interest was to insert faults in the
B. I2C Bus on CubeSats From a Reliability communication channel between the CubeSat subsystems.
Perspective The faults injected were presented as false values and change
The most employed data bus in CubeSats is I2C bus, the of electrical signals using two types on fault injection: Driver
percentage of CubeSats that employ I2C bus are 71% and 81% Fault and Interceptor Fault, the former simulate errors by
for launched and to be launch CubeSats accordingly. The injecting faults on the communication channel and the letter
second most employed data bus in CubeSats is RS-232 with emulate a faulty communication channel by injecting faults.
53% for deployed CubeSats and 45% for to be deployed Authors emphasized on the importance of utilizing Failure
CubeSats. Followed by SPI with 50% of deployed CubeSats. Emulator Mechanism (FEM) to increase the CubeSats’
Other least employed data buses are namely: CAN, USB, and robustness; by allowing enhancements during the
UART. In addition, some CubeSats use wireless data channels development phase [10].
for intra data exchange between on-board peripherals, such as Other researchers investigated the vulnerabilities of I2C bus
Wi-Fi and Bluetooth [2]. failure, and its resulting errors being generated by
Besides bus popularity, bus reliability is an important aspect continuously monitoring the I2C bus using external device
to investigate. The research published by Bouwmeester et al. that sits invisible. The monitor is designed to analyze the data
[2] focused on I2C, SPI, and RS-232, and the number of being transmitted over the I2C bus, understanding the packet
CubeSats that employed each data bus were 37, 23, and 24 structure and communication messages. Then it generates
respectively. The failure tolerance techniques investigated signals which summarizes the failures occurred on the bus and
were error signaling line, bus lockup protection, recovery actions. The monitor’s implementation allows
supplementary watchdog circuitry, etc. Among all missions, checking the success of the data transactions by calculating the
42% of mission used RS-232 bus with no fault tolerance, 35% checksum of the data transmitted or detecting NACK signal
of missions using SPI, and 16% of missions using I2C; thus, it on the bus. Additionally, allowing fault recovery by forcing
was clear that I2C bus was the highest to have failure tolerance the I2C master to reset [3].
techniques. Furthermore, the most common failure tolerance Several approaches have been applied to increase the I2C
techniques implemented amongst the surveyed missions were bus reliability and robustness, with the price of additional cost,
having supplementary watchdog timer 54% of mission, rules, hardware, and processing. Ryan F. et al. [11] presented
implementing bus lockup protection 49% of missions, and a designed developed by California Institute of Technology,
deploying separate buses connection to different subsystems the design has two I2C cores that regularly send messages to
30%. slaves to check if they are alive. Patrick B. et al. [12] proposed
The overall mission data bus success reported 95% of an approach to monitor the I2C bus for lockups and alert the
missions using RS-232 did not report any issue with the bus, master in case a lockup was detected. The work presented by
followed by SPI with 94%, and finally 40% for missions using [13] Intel Corporation proposed SMBus which is a protocol
I2C. It was clear from the survey that CubeSat developers and that runs on the I2C bus, the SMBus uses additional set of rules
operators had reported many issues with the I2C bus, the most to control the data transmission over the I2C bus targeting
reported failure was bus lockups with 43% of cases that lasted various categories such: electricals, timing, protocols, and
for more than 1 minute and 21% for less than one minute. operating modes. The SMBus sets many rules that the I2C bus
Other issues with I2C bus were loss of packet transmission does not support such as minimum clock frequency,
21%, catastrophic hypothesis 7%, 3% for proven catastrophic cumulative clock low extend time for slave, clock low time-
failure, 3% high bit error rate and 3% performance out, etc. Such features give SMBus more reliability over the
degradation. Example of CubeSats with such I2C failures are: I2C bus but lowers the compatibility with I2C devices. F.
CP4 launched by California Polytechnic State University Mariajose [8] presented two methods to mitigated conflicted

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

addresses on the I2C bus, both methods require hardware to The hardware boards used were Arduino Uno, Arduino Mega,
be connected in addition to the conventional the I2C bus setup. and TI Tiva C Launch pad, in order to provide a variety of I2C
The first method utilizes additional multiplexer between the bus implementations. For monitoring the hardware and
I2C bus and slaves with conflicted address, the master device software components of each of the failure modes deferent
then enables the required slave electrically bus connecting it tools were utilized such as:
to the bus or isolating it. This method does not require
additional pins or control logic for I2C programmable devices. • Serial output monitor, to capture the data
The second method is adding I2C buffer this method demands transmission on both master and slave sides.
additional lines and control logic depending on the devices • I2C packet sniffer, which was implemented using
used. Arduino MEGA board, to capture I2C packets being
transmitted between master and slaves and to
IV. Methodology monitor the data transmitted on the bus. Figure 3
The methodology used for this study included five stages as shows the output of the packet sniffer, showing the
highlighted in Figure 2. device address, read/ write operation and finally the
stream of bytes exchanged.
A. Data Collection
The data collection in this study was mainly based on literature
review and collecting observation from experimental testing.
The data collection to construct the initial list of hypothesized FIGURE 3 Example of I2C Packet Sniffer Output
failure modes was constructed by investigating previous
CubeSat missions’ failure analysis reports and published C. Testing Procedure
surveys. On the other hand, the data collected from the The testing procedure in this study followed three main steps,
experimental testing were based on collecting observations firstly by selecting the topology setup of the I2C bus by
from setups simulating the hypothesized failure modes. determining the number of slaves and the population of the
devices on the I2C bus. The experimental setup is used to run
a set of pre-identified tests to stress the I2C bus using different
Commercial-Off-The-Shelf (COTS) development hardware.
The different hardware and software selection were based on
the need to fulfil the aim of each test scenario to generate a
failure mode and to detect the cause of that failure mode.

D. Propose Mitigation Techniques

Based on the observations made during the experimental
testing, different approaches were proposed to overcome the
failure modes. Each failure mode was examined individually
to propose methods utilizing hardware and/or software
components to mitigate the root cause leading to that failure
by either eliminating it or reducing its likelihood and
consequence.

E. Risk Analysis
The best way to analyze and evaluate the data collected is
by conducting a qualitative risk analysis, since the data
obtained from testing were mainly based on observation and
no quantitative output were recorded.
Qualitative risk analysis is a helpful tool to measure the risk
associated to the I2C bus failure and to help minimize the risk
of failure thus increasing the I2C bus reliability.
FIGURE 2. Methodology used for the Study
The qualitative risk analysis conducted in this study is based
on six main steps:
B. Experimental Setup 1. Determination of risk phase, whether it is an
implementation risk that occurs in the development
The experimental setup was constructed using selected phase or a mission risk that occurs during operation
hardware, software, and monitoring tools to conduct the phase.
testing scenarios. For each of the hypothesized failure mode
different hardware and software components were utilized.
4

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

2. Definition of risk parameter, each risk is mapped to 5. Re-evaluate the risk after mitigation technique
a probability and consequence level of seriousness as implementation, based on likelihood and
shown in Table 1 and Table 2. consequence.
6. Defining the net risk, which is the risk remaining
Table 1 Risk Consequence after the mitigation techniques is applied.
# Consequence Description
Minimal or no impact on mission V. Results
1 Very Low
objectives In this section, the results of the experimental testing for
2 Low Minimal reduction in mission return each of the hypothesized failures is presented, the I2C bus
failures were observed either as bus lockups where the data
3 Moderate Cannot meet full mission success transmission on the bus was lost, or as corrupted data where
4 High Cannot meet minimum mission success the data received by the peripheral’s did not match the
message sent. The most common I2C failure was bus lockups,
5 Very High Mission catastrophic
based on the different hypnotized scenarios bus lockups
occurred either due to hardware or software issue; therefore,
Table 2 Risk Likelihood hardware components and software tools were utilized to
# Likelihood Description emulate the failure scenarios and detect the causes leading to
it. The study detected four causes that lead to bus lockups: the
1 Very unlikely May occur in exceptional
value of the pullup resistor, infinite loops, device state, and
circumstances
missing acknowledgements. In addition, data corruption
Unlikely to occur but could occur under
2 Unlikely occurred due to conflicted addresses or loss of synchronization
some circumstances between devices.
3 Possible Moderately likely to occur The rest of the section will discuss each failure cause and
explain the test conducted to detect it.
4 Likely Will probably occurs at some time
5 Very Likely Is expected to occur A. Pullup Resistor Value
In this test, the pullup resistor value effect on the I2C bus
behavior was tested by connecting a single master device to
3. Map the risk to the risk-matrix as shown in Figure 4 two slaves. The theoretical value of the pullup resistor for the
a. [L] Green corresponds to low impact experimental setup was calculated and found to fall between
b. [M] Yellow corresponds to medium impact minimum 1.5kΩ and maximum 2.95kΩ. In this experiment the
c. [H] Red corresponds to high impact pullup resistor values were varied, and the I2C bus behavior
was observed. The value that caused a bus lockup was resistor
value of 100 Ω and below; the value of the resistor is subjected
to the node population on the bus; thus, it differs based on the
mission design. One factor to notice is that with several COTS
nodes (subsystems and components) added to the spacecraft
I2C bus, the value of the pull-up resistors build-up, which will
impact the quality of the SCL signal as observed in the
waveforms in figure 5. This leads to the malfunctioning of the
FIGURE 4 Risk Priority Matrix
bus operations.

4. Propose mitigation techniques, that can help in

solving or reducing the risk. Four approaches are
possible:
• Treat: by having an action plan to take if the risk
occurs which results in reducing either the
likelihood, consequence, or both.
• Terminate: by applying enough margins, perform
tests and simulations to eliminate the risk.
• Transfer: by having insurance or a third party to
handle the risk.
• Tolerate: is when no action can be taken, and the
risk must be accepted.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

remained at almost 5V after disconnection. Different hardware

act differently on the I2C bus, in this case turning the Arduino
board OFF while connected to the I2C bus acted as circuit
ground and dropped the voltage on the bus which leaded to
bus lockup. One the other hand, TIVA C is design to isolate
the I2C bus from ground when it is switched OFF. Thus, slave
devices should not have the ability to pull the bus low unless
transmitting data over the SDA line.

Table 3 SDA and SCL Lines Voltage

Device State SDA (v) SCL (v) Lines Connected

ON 4.7 4.7 All
OFF 0.96 0.96 GND, SDA, SCL
FIGURE 5 SDA (yellow) and SCL (Blue) Waveforms with Pullup OFF 1.3 0.02 SDA, SCL
Resistor Value of 100 KOhm
OFF 4.9 4.9 None
B. Infinite Loops
The I2C bus protocol software design is based on interrupts
D. Missing Acknowledgment
and register states, meaning that all data transmissions and
Acknowledgements are an important part of the I2C
control signals are being handled by the Two Wire Interface
protocol definition. For this test, the effect of a missing
(TWI) registers. The simple design of the protocol lacks
acknowledgement was investigated by disabling one
failure and error handling and sets numerous infinite loops to
acknowledgement statement from the slave controlling the bit
wait for register states to change, such as: wait for start
assignments TWINT, TWEA, TWEN, and TWIE of the Two
condition as shown in eq. 1, if the device was unable to set the
Wire Control Register (TWCR) register as shown in eq. 2.
TWCR register then the I2C bus would lock up.

𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 = (1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇)|(1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇)|(0 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇)); 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 = (1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇)|1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇|(1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇)|(1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇) (2)
//𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶
𝑊𝑊ℎ𝑖𝑖𝑖𝑖𝑖𝑖 �! �𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇&(1 ≪ 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇)�� ; (1) The failure of the slave to set the TWCR register or the loss
//𝑐𝑐ℎ𝑒𝑒𝑒𝑒𝑒𝑒 𝑓𝑓𝑓𝑓𝑓𝑓 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 of the acknowledgement on the SDA line led to I2C bus
lockup, where the master did not have the ability to
communicate with any of the other slaves on the bus.
Infinite loops are also implemented with
acknowledgements and stop conditions, which can be E. Conflict Address
extremely critical in terms of software reliability. For simple The I2C bus can be implemented by either allocating 7-bits
I2C implementation and utilizing non programable devices, or 10-bits for the address which allows having 128 or 1024
failing to execute a start, stop, or acknowledgement statement addresses. The limited range increases the probability of
was found to lead to bus lockups. having two slaves with the same address on the bus, which
leads to corrupted data transmission on the I2C bus as both
slaves reply at the same time. Moreover, slaves with
C. Device State hardcoded addresses suffer this problem unlike I2C slaves
The device state being ON or OFF while connected to the which allow the modification of their address either by
I2C bus was tested, by examining the voltage on the bus using programming or having configuration pins to flip a bit or two.
two different I2C slaves (AVR processor on the Arduino UNO Conflicting addresses was found to lead to corrupted data, i.e.,
and the TM4C123 processor on the TIVA C board). the data received did not match the data sent.
In normal cases I2C slaves can only pull the bus low to
enable the bidirectional communication when transmitting F. Device Synchronization
data to the master. In this experiment the normal bus voltage The I2C protocol depends on clock signals from the master
was held high at +5V, and then disconnecting the power of the device to control all transactions, and synchronization faults
Arduino slave (OFF) while it is connected to the I2C bus, between I2C devices happen when the master encounters a
hence leading to voltage drop to less than 1V on both SDA and sudden restart while communicating with I2C slaves. The I2C
SCL lines as shown in Table 3. This sequence was found to protocol does not define device state messages, thus, the slave
cause a bus lockup. On the other hand, the same test was devices do not get updated by the sudden restart. The
repeated using a TIVA C slave, the voltage on both lines observation made by this experiment is that slaves continue

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

sending the data from last stopped byte, which results in phase. The I2C protocol design assigns several infinite loops,
having data at the master end that does not match the originally the control signals on the bus depend on register assignments
sent, hence leading to data corruption. and the devices wait indefinitely for the register assignments
to succeed, and the failure of assigning the register leads to bus
VI. Discussion and Practical Implication lockup. Thus, developers should implement timers to exit
The usage of the I2C bus on-board CubeSats can lead to loops and enforce the slave devices to release the bus.
catastrophic failures for missions, due to the I2C bus related Also, the I2C protocol defines waiting time for
risks and the unpredictability of their occurrence. Therefore, acknowledgement on both master and slave sides, if the
constructing a robust risk mitigation plan for CubeSat acknowledgment is lost or corrupted during the transmission
missions is essential, considering the different development then the I2C bus gets locked because the receiver device will
phases of the project and the various aspects that must be keep on waiting for the lost acknowledgement. Thus, software
counted for. Thus, significantly reducing the impact of the development shall consider releasing the bus after a
risks or the frequency of occurrence. A summary of the risks predefined wait-time.
associated with the I2C bus and their respective mitigation Furthermore, some I2C slaves suffer from synchronization
techniques is presented in Table 4. with the master device, this happens after an unscheduled
During the design phases, CubeSat developers should master restart. The unsynchronized slave devices then transmit
examine both: the individual I2C slave device/nodes and the faulty values, in which it can be overcome by having a
design of the I2C bus. scheduled reset to the slave devices after the master’s reset.
Firstly, the I2C slave addresses must be ensured to be In addition, CubeSat developers must ensure having
unique; in case of encountering conflicted address, developers watchdog timer on-board, in which it can reset the devices in
are expected to resolve the issue by either implementing case of exceeding an idle time of no communication
hardware or software solution. The simplest approach with happening in the I2C bus. And it is important to note the
programmable devices is to reprogram the address, but in assigned wait time of the devices should not exceed the idle
many cases this solution is not feasible for I2C slaves as the time of the watchdog timer.
simplicity of their design does not support programmability. Besides the key factors that ensure the reliability of the I2C
Thus, the issue of having slaves with conflicted address can be design it is important to be consider future run-time risks
solved using hardware solutions such as: exchanged the which should be addressed at the implementation phase.
conflicted slave with other slaves, connect slaves with
conflicted addresses to different I2C busses, connect
conflicting slaves via multiplexers [8], or connect conflicted
slaves through I2C buffers [8]. Hardware solutions demand
additional hardware in addition to software modification,
which adds complexity to the solution.
Second aspect to be investigated during the design phase is
the device electronic design characteristics, mainly the effect
of the slave on the I2C bus in case of having faulty power
supply to that slave. Some slaves pull the bus low in case of
losing the power supply, this failure can be avoided by
isolating the slave from the I2C bus by utilizing additional
hardware, such as connecting the slave device an I2C buffer.
Thirdly, CubeSat developers should always ensure
appropriate voltage levels on SDA and SCL lines. The SDA
and SCL lines should be held high voltage when idle, and this
is achieved by integrating pullup resistors. Some I2C slaves
come with integrated internal pullup resistors but connecting
an external pullup resistor ensures a more robust design.
Also, considering the I2C slave capabilities is critical for
CubeSat software design, because the consequence of
exceeding the slaves’ capabilities would lead to getting
unexpected errors. For example, the data buffer size, the
master device should not transfer data at a rate that would
overload the slave buffer size. Thus, the software design
should adhere to the slaves’ specifications.
Additionally, the I2Cbus protocol suffers several software
vulnerabilities which should be considered during the design

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

Table 4 I2C Qualitative Risk Analysis

Consequence

Consequence
Likelihood

Likelihood
Risk Mitigation Net risk

Level

Level
Type
Reduced consequence and likelihood of
Terminate: Employ bus isolators
Faulty device (OFF) on the for devices cause the risk. occurrence, under normal circumstances.
I2C bus. M 5 3 H 1 1 L

Terminate: Test slaves’ Reduced consequence and likelihood of

Data request with high capabilities and apply control occurrence, when transmitting within
number of bytes. M 3 4 M 1 1 L
over the maximum data size. calculated data size.
Fault may occur but the probability of
Treat: Implement enforced bus
Missing acknowledgment from release with loop break. the bus getting locked up is much
a slave. M 5 5 H 2 2 L
lower.
Unsynchronized devices on the Treat: Schedule resets and reset Reduced consequence and likelihood of
M 3 4 M 2 2 L
I2C bus. slave after OBC reset. occurrence.
Terminate: Test slaves’ address
Fault terminated unless hardware damage
Devices with conflicted uniqueness prior to launch and happens after deployment.
addresses on the I2C bus. I 4 1 L 1 1 L
isolate conflicted address.
Terminate: Design bus nodes
High number of I2C nodes. I 3 3 M number based on capacitance 2 1 L Fault terminated.
with margin.
Terminate: Test wire
Lengthy I2C bus line. I 3 3 M 1 1 L Fault terminated.
length with margin.
Treat: Implement timers to break
Software infinite waiting Reduced consequence and likelihood of
loops. M 4 5 H loops, add watchdog timers. 2 2 L occurrence.
Terminate: Employ pullup Fault terminated, when implemented
High pull up resistor value. I 4 3 M resistors with enough margin. 1 1 L with enough margin.

Terminate: Employ pullup Fault terminated, when implemented

Low resistor value. I 4 3 M resistors with enough margin. 1 1 L with enough margin.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4.0/
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

[11] Ryan F., Leonard D., H. Luong, Robert R., Savio C., “I2C bus protocol
VII. CONCLUSION controller with fault tolerance” U.S. Patent 6,728,908, 27 April, 2004.
[12] Patrick B., Daniel H., Vinh L., Kirby W., Lee W., “Systems and
methods for correcting errors in I2C bus communications” U.S. Patent
Although the I2C bus is commonly used on-board CubeSat 0240019A1, 11 Oct., 2007.
missions, and is deemed responsible for several mission [13] System Management Bus (SMBus) Specification, 2000
[14] Bouwmeester, J., Guo, J.: Survey of worldwide pico- and nanosatellite
failures, there is a lack of a comprehensive study on the
missions, distributions and subsystem technology. Acta
possible causes of I2C related failure, and their possible Astronaut. 67(7), 854–862 (2010)
mitigation techniques. Previous research lacked the [15] M. Noca, F. Jordan, N. Steiner, T. Choueiri, F. George, G.
investigation of the root causes of I2C failure, where only few Roethlisberger, N. Scheidegger, H. Peter-Contesse, M. Borgeaud, R.
Krpoun, et al., “Lessons learned from the first Swiss pico-satellite:
failure triggers were identified. In this paper, we investigated
SwissCube,” Proceedings of the 23rd Annual AIAA/USU Conference on
some of the suspected I2C failures that were encountered by Small Satellites, 2009.
past CubeSat missions, and hence to confirm the occurrence [16] N. Cornejo, J. Bouwmeester, G. Gaydadjiev, “Implementation of a
of the hypothesized failures by conducting experimental reliable date bus for the Delfi programme,” Small Satellites for Earth
Observation: 7th International Symposium of the International Academy
testing. The paper shows that the I2C bus design suffers
of Astronautics (IAA), 4-8 May 2009, Berlin, Germany, 2009.
hardware and software issues when implemented in CubeSats, [17] E. Oland, “The HiNCube student satellite - lessons learned,”
due to various reasons including, bus simplicity (and hence Proceedings of the 7th International Conference on Recent Advances in
lack of fault detection mechanism), the harsh space Space Technologies, 2015, pp. 429–432.
[18] G. Manyak, J. Bellardo, “PolySat’s next generation avionics design. In:
environment, and the lack of shielding. Previous research
Fourth IEEE International Conference on Space Mission Challenges for
identified catastrophic failures of CubeSat missions with the Information Technology, Palo Alto, 2011
hypothesis that the failure occurred due to I2C bus failure, yet [19] J. Bouwmeester, L. Rotthier, C. Schuurbiers, W. Wieling, G. Van der
no further risk analysis was conducted to measure the impact Horn, F. Stelwagen, E. Timmer, M. Tijssen, “Preliminary results of the
Delfi-n3Xt mission,” In: Proceedings of the 4S Symposium, Porto Petro
of I2C bus failure on the overall CubeSat mission success. In (2014)
this paper, out of ten identified risks related to the I2C bus, [20] B. O. Alnaqbi, H. S. A. Messabi, H. AlYassi, M. Alawania, M. S.
three of them were identified as high-risk vulnerabilities, six Mansouri, T. Vu, et al., "The first UAE multi-disciplinary space program",
as medium-risk and one as low-risk. Faulty on-board devices 23rd IAA Symposium on Small Satellite Missions, pp. 1-7, June 2016.
[21] A.-H. Jallad, P. Marpu, Z. Abdul Aziz, A. Al Marar, and M. Awad,
are of particular concern, as they are highly likely and can lead “MeznSat—A 3U CubeSat for Monitoring Greenhouse Gases Using Short
to serious consequences on the mission. The paper proposes Wave Infra-Red Spectrometry: Mission Concept and Analysis,” Aerospace,
different mitigation methods, some that consent with other vol. 6, no. 11, p. 118, Oct. 2019, doi: 10.3390/aerospace6110118.
research proposals, and other new proposed approaches, [22] M. Holliday, Z. Manchester and D. G. Senesky, "On-Orbit
Implementation of Discrete Isolation Schemes for Improved Reliability of
which CubeSat mission developers should consider when
Serial Communication Buses," in IEEE Transactions on Aerospace and
developing CubeSat; to eliminate failures and/or reduce their Electronic Systems, vol. 58, no. 4, pp. 2973-2982, Aug. 2022, doi:
impact on CubeSat missions. Additionally, the paper also 10.1109/TAES.2022.3142713.
presents a risk mitigation procedure for CubeSat developers to
consider when utilizing I2C bus in their missions.
AMINA ALBALOOSHI was born in Kingdom of
Bahrain. She received MSc degree in Engineering
REFERENCES Systems and Management with Space Systems and
Technology from Khalifa University, in 2021 and
[1] M. Swartwout, “The First One Hundred CubeSats: A Statistical Look”, BSc degree in Computer Engineering from
Journal of Small Satellites, vol. 2, no. 2, pp.213-233, 2013 University of Bahrain, in 2016. From 2018 to 2019,
[2] J. Bouwmeester, M. Langer, and E. Gill, “Survey on the implementation she was a Network Engineer with Batelco. Since
and reliability of CubeSat electrical bus interfaces,” CEAS Space Journal, 2019, she has been Senior Space Engineer with the
vol. 9, no. 2, pp. 163–173, 2016. National Space Science Agency, Kingdom of
[3] V. Carvalho and F. L. Kastensmidt, “Enhancing I2C robustness to soft Bahrain. Her research interest includes CubeSat
errors,” in 2017 IEEE 8th Latin American Symposium on Circuits & development, CubeSat Risk Management, and Failure Detection Isolation and
Systems (LASCAS), 2017. Recovery.
[4] S. Van der Linden, J. Bouwmeester, A. Povolac, “Design and Validation
of an Innovative Data Bus Architecture for CubeSats,” Proceedings of the ABDUL-HALIM M. JALLAD (Member, IEEE)
Reinventing Space Conference,2016 received his Ph.D. degree from the University of
[5] J.Valdez, J.Becker, “ Understanding the I2C Bus,” Application Report, Surrey, UK, in 2009, and the BEng degree from
Texas Instruments, Jube 2015. Available online: the University of Kent, UK, in 2003 after receiving
https://www.ti.com/lit/an/slva704/slva704.pdf several academic achievement prizes. At the
[6] R.Arora, “I2C Bus Pullup Resistor Calculation,” Texas Instruments, University of Surrey, he was a member of the
2015 Surrey Space Centre where he was involved in
[7] H. Askari et al, “Software Development for Galassia CubeSat – Design, several research and development projects in
Implementation and In-Orbit Validation,” 2017 collaboration with Surrey Satellite Technology
[8] M. Ferrando, “Troubleshooting I2C Bus Protocol,” Texas Instruments, Limited (SSTL), a world leader in the development of small satellites.
2009 Currently, he is with the Department of Electrical Engineering and the
[9] L. Kepko et al, “Dellingr: Reliability Lessons Learned from On-orbit,” National Space Science and Technology Centre at the United Arab Emirates
Conference on Small Satellites. University. Prior to that, he served as the Director of the Center of Information,
[10] C. L. G. Batista, E. Martins, and M. D. F. Mattiello-Francisco, “On the Communication and Networking Education and Innovation (ICONET) at the
use of a failure emulator mechanism at nanosatellite subsystems integration American University of Ras Al Khaimah (AURAK). His research interests
tests,” 2018 IEEE 19th Latin-American Test Symposium (LATS), 2018. include embedded systems, Internet of Things, system-on-chip design,

VOLUME XX, 2017 9

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4
 This article has been accepted for publication in IEEE Access. This is the author's version which has not been fully edited and
content may change prior to final publication. Citation information: DOI 10.1109/ACCESS.2023.3262410

spacecraft on-board data handling, middleware design, VLSI design and

reconfigurable architectures.

PRASHANTH R. MARPU (Senior Member, IEEE)

received his M.Sc. degree in wireless engineering from
the Technical University of Denmark in 2006, and his
Ph.D. degree from TU Freiberg, Germany in 2009. He
is working as Technical Lead- Space Program at Group
42, Abu Dhabi, UAE. He served as an Associate
Professor in the Department of Electrical Engineering
and Computer Science, Khalifa University of Science
and Technology (KUST), Abu Dhabi, UAE. He was involved in designing and
building small satellites as a Project Manager of four satellite projects. His
research interests include space systems, remote sensing, and machine
learning.

VOLUME XX, 2017 9

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License. For more information, see https://creativecommons.org/licenses/by-nc-nd/4