Patent Description:
Functional safety systems can be used in automotive, industrial, aerospace and other applications to provide automated protection against communication errors, equipment failures, or other faults in systems of the underlying application. Functional safety depends on proper operation of a system in response to inputs and predictable responses to human errors, software or hardware failures, environmental factors, and operational fatigue. Internal fault monitoring and protection can support the overall goal of functional safety by identifying faults and taking prompt action to correct or otherwise address the fault.

In electronic systems, integrated circuits associated with sensors, drivers, or other components may transmit status information indicating the current status of the components, including identifying when a fault condition is present, to a main microcontroller for the system. This status information can be used to alert the microcontroller to the existence of a fault condition, in response to which the microcontroller can perform predetermined operations to identify, diagnose, and address the fault. Serial communication can be used to economically and reliably communicate status information in an overall automotive, industrial, or other system. In an automotive system, for example, power management integrated circuits (PMICs), motor driver circuits, and sensor interface circuits may communicate with a microcontroller and can communicate commands, data, status, and other data during operation. <CIT> discloses a serial management interface master device including an input/output pin and a controller including an error code calculator. Further, <CIT> discloses a communication system in which a microcomputer for an electronic device and a peripheral device thereof are connected with each other by using serial communication interface function integrated in the microcomputer. XP002219808 discloses to transfer frames including data, status information and error code information.

The invention is described by the features of the appended claims.

In a first aspect, an apparatus includes a serial output communication pin and an interface circuit communicably connected to the serial output communication pin. The interface circuit is adapted to intermittently send an output serial data frame to a controller via the serial output communication pin. Each output serial data frame includes a status phase and a data phase followed by one or more fault bits. The one or more fault bits indicate whether a fault is detected during sending of the output serial data frame.

Implementations of the apparatus can include one or more of the following features. The apparatus includes a serial input communication pin communicably connected to the interface circuit, and the interface circuit is adapted to intermittently receive an input serial data frame from the controller via the serial input communication pin. Each input serial data frame includes a command, and the status phase includes status data for a command included in a preceding input serial data frame. A peripheral device is connected to the interface circuit, and the command included in the input serial data frame from the controller includes an instruction for the peripheral device. The one or more fault bits include a serial communication fault flag bit indicating whether a fault in the serial communication is detected and a peripheral device diagnostic detection fault bit indicating whether a fault is detected in the peripheral device. The controller is adapted to send commands to a plurality of interface circuits, and each interface circuit is connected to at least one corresponding peripheral device. The serial input communication pin is adapted to receive commands and operational data. The peripheral device is a power management integrated circuit, a motor driver, or a sensor. The apparatus includes an enable pin and a clock pin. The one or more fault bits include a fault flag bit indicating whether a fault is detected and a redundancy bit providing a redundant indication of whether a fault is detected. The output serial data frame includes a plurality of status bits, a plurality of data bits, and a plurality of cyclic redundancy bits, followed by the one or more fault bits. The apparatus includes a first peripheral device, and the interface circuit includes peripheral device interface circuitry adapted to communicate with a microcontroller using a serial communication protocol. The peripheral device interface circuitry is adapted to intermittently receive input serial data frames from the microcontroller using the serial communication protocol and to intermittently send output serial data frames to the microcontroller using the serial communication protocol. Each output serial data frame includes one or more status bits representing communication status data in the status phase and one or more data bits representing peripheral device data in the data phase. The interface circuit is adapted to communicate with the controller via a serial communication interface (e.g., a serial peripheral interface bus, an I<NUM>C communication bus, an I<NUM>S communication bus, or a universal asynchronous receiver/transmitter).

In a second aspect, an apparatus comprising an integrated circuit includes a plurality of pins, including one or more serial data communication pins, peripheral device interface circuitry configured to communicate with a microcontroller using a serial communication protocol, and one or more registers accessible by the peripheral device interface circuitry. The peripheral device interface circuitry is further configured to intermittently receive input serial data frames from the microcontroller via at least one of the one or more serial data communication pins using the serial communication protocol and to intermittently send output serial data frames to the microcontroller via at least one of the one or more serial data communication pins using the serial communication protocol. The one or more registers accessible by the peripheral device interface circuitry include a serial data output register adapted to store data for inclusion in the output serial data frames. The data includes one or more status bits representing communication status data, one or more data bits representing peripheral device data, and at least one fault bit. The peripheral device interface circuitry is configured to generate each output serial data frame using data stored in the serial data output register so that the output serial data frame includes the one or more status bits and the one or more data bits serially followed by at least one fault bit. The at least one fault bit indicates whether a fault is detected during sending of the output serial data frame.

Implementations of the apparatus can include one or more of the following features. The peripheral device interface circuitry is configured to store data from the input serial data frames in at least one of the one or more registers, and the input serial data frames include instructions for a peripheral device communicably coupled to the peripheral device interface circuitry. The integrated circuit includes logic configured to set, during sending of a particular output serial data frame, a value of the at least one fault bit in the serial data output register in response to detecting a fault in receiving the input serial data frame, and to include, in the particular output serial data frame, the value of the at least one fault bit in the serial data output register. The peripheral device interface circuitry is configured to set, during sending of a particular output serial data frame, a value of the at least one fault bit in the serial data output register in response to detecting a diagnostic fault in a peripheral device communicably coupled to the peripheral device interface circuitry and to include, in the particular output serial data frame, the value of the at least one fault bit in the serial data output register. The integrated circuit includes logic configured to set the one or more status bits for a particular output serial data frame to indicate whether a fault is detected; set, during sending of a particular output serial data frame and after setting the one or more status bits, a value of the at least one fault bit in the serial data output register in response to detecting a fault; and include, in the particular output serial data frame, the value of the at least one fault bit in the serial data output register.

In a third aspect, a method includes initiating sending of an output serial data frame that includes a status phase and a data phase to a microcontroller via a serial communication bus connected to the microcontroller, detecting a fault during sending of the output serial data frame, setting a fault flag in the output serial data frame in response to detecting the fault, and transmitting the fault flag in the output serial data frame.

Implementations of the apparatus can include one or more of the following features. Setting a fault flag in the output serial data frame in response to detecting the fault includes setting at least one fault flag bit in a register after transmitting at least one bit of the output serial data frame and inserting the at least one fault flag bit in the output serial data frame. The output serial data frame is sent by an interface circuit of a peripheral device, and the method further includes receiving the fault flag at the microcontroller and enabling a subsequent communication between the peripheral device and the microcontroller in response to receiving the fault flag at the microcontroller.

In some examples, an apparatus includes a peripheral device and peripheral device interface circuitry adapted to communicate with a microcontroller using a serial communication protocol. The peripheral device interface circuitry is adapted to intermittently receive input serial data frames from the microcontroller using the serial communication protocol and to intermittently send output serial data frames to the microcontroller using the serial communication protocol. Each output serial data frame includes one or more status bits representing communication status data and one or more data bits representing peripheral device data. The status bits and the data bits are serially followed by one or more fault bits indicating whether a fault is detected during sending of the output serial data frame.

Implementations of the apparatus can include one or more of the following features. The input serial data frames include instructions for the peripheral device. The peripheral device interface circuitry is adapted to set a value of the one or more fault bits in response to detecting a fault in receiving the input serial data frame. The peripheral device interface circuitry is adapted to set a value of the one or more fault bits in response to detecting a diagnostic fault in the peripheral device. The apparatus includes multiple peripheral devices, each peripheral device has corresponding peripheral device circuitry, and a serial communication bus connects the corresponding peripheral device interface circuitry for each of the peripheral devices to the microcontroller.

In some examples, a system includes a microcontroller, a serial communication bus connected to the microcontroller, and multiple peripheral devices connected to the serial communication bus. Each of the peripheral devices includes a corresponding interface circuit communicably connected to the serial communication bus and is adapted to intermittently send an output serial data frame to a controller via the serial output communication bus. The output serial data frame for a first peripheral device of the multiple peripheral devices includes a status phase and a data phase followed by one or more fault bits, and the one or more fault bits indicate whether a fault is detected during sending of the output serial data frame.

Implementations of the system can include one or more of the following features. The interface circuit for each of the peripheral devices is further adapted to intermittently receive an input serial data frame from a controller via the serial communication bus. The input serial data frame includes commands for at least one of the interface circuit or the peripheral device. The output serial data frame for each peripheral device includes a status phase and a data phase followed by one or more fault bits indicating whether a fault is detected during sending of the output serial data frame. The one or more fault bits indicate whether a fault for at least one of the interface circuit or the corresponding peripheral device is detected during sending of the output serial data frame. The one or more fault bits includes a primary fault bit and a redundancy bit. At least one peripheral device includes an actuator for a safety component, at least one peripheral device includes a sensor, and the microcontroller is adapted to send input serial data frames to an interface circuit corresponding to the actuator in response to data included in at least one output serial frame sent by the interface circuit corresponding to the sensor.

In some examples, status flags are provided to a control system (e.g., a microprocessor unit) by integrated circuits (e.g., power management integrated circuits (PMICs), motor driver integrated circuits, sensor interface integrated circuits) via serial communication. An intermittent (e.g., periodic or repeating but non-periodic) serial communication frame is used to send data between the integrated circuits and the control system. The serial communication frame can include status data, device data, and cyclic redundancy check (CRC) data. The status data can provide communication status, for example, regarding whether a previous serial communication frame was properly received. Other status data may also be included. The device data can include, for example, any data that the integrated circuit or a connected device (e.g., a power management subsystem, a motor driver or motor, or a sensor) is programmed or otherwise constructed to send to the control system. The CRC data can include any data that facilitates confirming that the serial data frame is correctly received.

In addition, status flags can also be included in the serial communication frame to provide information indicating whether a fault occurs during the serial communication frame to the control system, including if something goes wrong with the current serial communication. Thus, the control system can be informed of a new fault before the next serial communication frame. This capability avoids latency of the overall system's ability to detect and react to a fault detection and, in some cases, may avoid a need for higher frequency polling of fault flags through serial communication, which can put an additional burden on software and serial communication in the system.

<FIG> depicts an illustrative example of a multi-component system <NUM>. The system <NUM> includes a microprocessor <NUM>. The microprocessor <NUM> can operate as a controller for a plurality of components. For example, the components in the illustrated example include sensors <NUM>, a power supply (e.g., with integrated monitoring and protection) <NUM>, and an actuator <NUM> (e.g., for a motor driver). The microprocessor <NUM> can include a microprocessor unit or microcontroller <NUM> that operates as a master controller for the components in the multi-component system <NUM>. The components can operate as peripheral devices under control of the microprocessor <NUM>. Although only one block each is illustrated for sensors <NUM>, power supply <NUM>, and actuator <NUM> for convenience, a multi-component system <NUM> can include multiple different sensors <NUM>, power supplies <NUM>, and actuators <NUM> that can perform redundant or different functions. In some implementations, the components can communicate with other controllers or systems as part of their operation.

Each of the sensors <NUM> can include a sensor <NUM> with an interface integrated circuit (IC) that can send sensor data to the microprocessor <NUM> and receive commands from the microprocessor <NUM> via a two-way communication bus <NUM> (e.g., a serial communication bus). The power supply <NUM> can include a power management integrated circuit <NUM> that can send power management reporting data to the microprocessor <NUM> and receive commands from the microprocessor <NUM> via a two-way communication bus <NUM>. The actuator <NUM> can include a pre-driver <NUM> that includes a pre-driver integrated circuit and can send actuator or motor data to the microprocessor <NUM> and receive commands from the microprocessor <NUM> via a two-way communication bus <NUM>. The pre-driver <NUM> can control, and receive monitoring data from, power stages <NUM> (as indicated at <NUM>), which in turn drive motors <NUM> (as indicated at <NUM>). The power management integrated circuit <NUM> can control a power supply to the various other components (as indicated at <NUM>). In some implementations, the pre-driver <NUM> can communicate with the power management integrated circuit <NUM> (as indicated at <NUM>), directly (i.e., through a dedicated or shared bus between the pre-driver and the power management integrated circuit <NUM>) or via the microprocessor <NUM>. The sensors <NUM> can also provide data to the power management integrated circuit <NUM> (as indicated at <NUM>), directly or via the microprocessor <NUM>.

The microprocessor <NUM> can control serial communications on shared bus lines by selectively enabling communications with the integrated circuits of each of the components <NUM>, <NUM>, and <NUM> (e.g., to allow only one component to communicate on a particular bus line during any given time period). In various implementations, the integrated circuits of each of the components <NUM>, <NUM>, and <NUM> can be embedded in the respective component <NUM>, <NUM>, or <NUM> or can be a separate component that is electrically and/or communicably connected to the respective component <NUM>, <NUM>, or <NUM>. In some implementations, the system <NUM> can include multiple microprocessors <NUM> that, for example, control different parts of an overall system. The system <NUM> can also be a subsystem of a larger system and/or can have multiple subsystems, which may also be described as a system. The system <NUM> can implement functional safety features through, for example, communications between the various components and the microprocessor <NUM>.

<FIG> is a vehicle system <NUM> that includes an example implementation of the multi-component of <FIG>. The vehicle system <NUM> includes an automobile <NUM> with a microprocessor <NUM> that monitors and controls various subsystems in the automobile <NUM>, including a brake sensor <NUM>, a steering sensor <NUM>, a power management integrated circuit <NUM>, and a brake actuator <NUM>. The microprocessor <NUM> controls power to the various components <NUM>, <NUM>, <NUM>, and <NUM> in response to data signals from the power management integrated circuit <NUM>. Alternatively, the power management integrated circuit <NUM> controls power to the various components <NUM>, <NUM>, <NUM>, and <NUM> independently or in response to data signals from the microprocessor <NUM>. The microprocessor <NUM> also receives signals from the brake sensor <NUM> and the steering sensor <NUM> and can issue commands in response to the sensor signals. For example, the microprocessor <NUM> can issue commands to the brake actuator <NUM> to perform an anti-lock brake function in response to data received from the brake sensor <NUM>, and the microprocessor <NUM> can issue commands to the power management integrated circuit <NUM> to provide or cut off power to another component in response to data received from the steering sensor <NUM>. The illustrated components <NUM>, <NUM>, <NUM>, and <NUM> are just an illustrative example. Any number of other components and other functions can also be controlled by the microprocessor <NUM> in response to data signals (e.g., traction control, anti-lock braking, power steering control, driver warning indicators, automated cruise control adjustments, self-driving functions, engine control, etc.).

Functional safety operations in the vehicle system <NUM> rely on near real-time status updates from the various components <NUM>, <NUM>, <NUM>, and <NUM> to detect and address faults in the operation of the overall vehicle system <NUM>. Near real-time functionality can be determined based on a desirable or necessary degree of responsiveness for a particular safety operation. For some operations, near-real time functionality can be on the order of microseconds or milliseconds. Faults can include communication errors (e.g., incorrectly received data frames, missing data acknowledgements, CRC errors, or clock errors), diagnostic faults (e.g., sensors detecting a problem condition, missing sensor data, overvoltage or undervoltage conditions, other device or power failures, or out-of-range thermal conditions), or any other types of faults that can impact the safe and proper operation of the overall vehicle system <NUM>. Microprocessor-based functional safety operations can also be used in other contexts, including, without limitation, industrial safety, aerospace, public transportation, etc. Status updates can be sent, for example, using serial communication (e.g., serial peripheral interface (SPI) bus, an I<NUM>C communication bus, an I<NUM>S communication bus, a universal asynchronous receiver/transmitter, or another serial communication technique).

<FIG> shows a waveform timing diagram <NUM> for a frame <NUM> of a serial peripheral interface (SPI) bus that is used to communicate between a master controller and a peripheral device interface. The master controller can be a microprocessor (e.g., the microprocessor <NUM> of <FIG> or the microprocessor <NUM> of <FIG>), and the peripheral device can be a component (e.g., any of the components <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> of <FIG>) that is at least partially controlled by, or reports to, the master controller. In various implementations, the peripheral device can be an integrated circuit embedded in a component (e.g., a sensor, power supply, or driver) or an interface integrated circuit that handles communications for a separate component (e.g., an interface circuit for a sensor, power supply, or driver). In some situations, the component can be referred to as the peripheral device and can have a corresponding peripheral device interface circuit. In addition, although the frame <NUM> is referred to in the singular, the frame <NUM> represents a bi-directional communication, and the communication in each direction can separately be referred to as a frame, including in implementations where the input and output data are not sent simultaneously.

The frame <NUM> includes a plurality of timeslots <NUM>, which may be arranged in phases (e.g., subframes). In the illustrated example, the frame <NUM> includes <NUM> timeslots, including a command phase <NUM>, a data phase <NUM>, and a cyclic redundancy code (CRC) phase <NUM>. The frame <NUM> represents a two-way communication between the master controller and the peripheral device, where input data in one direction is transmitted at the same time (i.e., during the same frame interval) as output data transmitted in the other direction. Communication with the peripheral device can be enabled using a low value of a chip select signal <NUM> (e.g., on a Chip Select Not (NCS) pin). In alternative implementations, a high value can be used on a chip select pin to enable communications via the peripheral device interface. The NCS pin allows a serial communication clock signal (SCLK) <NUM>, a serial data input (SDI) signal <NUM>, and a serial data output (SDO) signal <NUM> to be sent on serial communication bus lines that are shared between multiple peripheral device interfaces and the master controller. Input and output in this context are from the perspective of the peripheral device. The peripheral device interfaces are serially enabled by the master controller using a low signal on their respective chip select pins. In the illustrated example, one bit is transmitted in each timeslot <NUM>, and each timeslot is signaled by a high value of the clock signal <NUM>.

The command phase <NUM> includes eight timeslots beginning with a first timeslot <NUM>(<NUM>) (and followed by a second timeslot <NUM>(<NUM>), a third timeslot <NUM>(<NUM>), and so on) and ending with an eighth timeslot <NUM>(<NUM>). During each timeslot <NUM> of the command phase <NUM>, a command bit (CMD[n]) <NUM> is transmitted by the master controller to the peripheral device interface and a status bit (STAT[n]) <NUM> is transmitted by the peripheral device interface to the master controller. The command bits <NUM> individually or collectively can communicate one or more commands to the peripheral device. The status bits <NUM> can communicate a status response to a previous command (e.g., data regarding whether the command was properly received, any errors in the communication, and/or a status of execution of the command) and other peripheral device status information.

The data phase <NUM> includes eight timeslots beginning with a ninth timeslot <NUM>(<NUM>) of the frame <NUM> and ending with a <NUM>th timeslot <NUM>(<NUM>). During each timeslot <NUM> of the data phase <NUM>, a master data bit (DATA[n]) <NUM> is transmitted by the master controller to the peripheral device interface and a peripheral data bit (R[n]) <NUM> is transmitted by the peripheral device interface to the master controller. The master data bits <NUM> can communicate, for example, data associated with the commands (e.g., values used in executing the commands) to the peripheral device interface. The peripheral data bits <NUM> can communicate data that the peripheral device interface is sending out to the master controller (e.g., for use by the master controller in performing operations or for communication to other peripheral devices).

The CRC phase <NUM> includes eight timeslots beginning with a <NUM>th timeslot <NUM>(<NUM>) of the frame <NUM> and ending with a <NUM>th timeslot <NUM>(<NUM>). Some timeslots <NUM>(<NUM>)-<NUM>(<NUM>) are reserved in the illustrated example, including reserved (RSV) bits <NUM> of the serial data input signal <NUM> and the serial data output signal <NUM>. During each of the remaining timeslots <NUM>(<NUM>)-<NUM>(<NUM>) of the CRC phase <NUM>, a master CRC bit (MCRC[n]) <NUM> is transmitted by the master controller to the peripheral device interface and a peripheral CRC (SCRC[n]) bit <NUM> is transmitted by the peripheral device interface to the master controller. The master CRC bits <NUM> and the peripheral CRC bits <NUM> provide cyclic redundancy check data to enable the receiving device to check that the data in the frame is properly received and in some cases to correct errors in the received data.

In some implementations, the command bits <NUM>, status bits <NUM>, master data bits <NUM>, and peripheral data bits <NUM> (or some subset thereof) can indicate that the applicable data is stored in a register or a particular location of a register instead of communicating the data directly. For example, the status bits <NUM> can indicate to the master controller an address in a register where the applicable status data has been placed by the peripheral device or the peripheral device interface. Similarly, the command bits <NUM> can indicate to the peripheral device interface an address in a register where the applicable command data has been placed by the master controller. Thus, the command bits <NUM>, for example, can constitute a command even if the some or all of the instructions of the command are stored in a separate register at a predetermined location or at an address identified by the command bits <NUM>.

<FIG> shows a waveform timing diagram <NUM> for a sequential pair of frames <NUM>(<NUM>) and <NUM>(<NUM>) of the serial peripheral interface (SPI) bus described in connection with <FIG>. The first frame <NUM>(<NUM>) is not necessarily first in a sequence of frames but can be a frame n in a sequence of frames sent between the master controller and a particular peripheral device interface, while the second frame <NUM>(<NUM>) is the next serial frame n+<NUM> in the sequence of frames sent between the master controller and the particular peripheral device interface. The first frame <NUM>(<NUM>) includes a command phase <NUM>(<NUM>), a data phase <NUM>(<NUM>), and a CRC phase <NUM>(<NUM>). The command phase <NUM>(<NUM>) of the first frame <NUM>(<NUM>) can include one or more status responses (e.g., encoded in a serial data output signal <NUM>) to one or more commands received in a previous frame. The second frame <NUM>(<NUM>) includes a command phase <NUM>(<NUM>), a data phase <NUM>(<NUM>), and a CRC phase <NUM>(<NUM>). The command phase <NUM>(<NUM>) of the second frame <NUM>(<NUM>) can include one or more status responses (e.g., encoded in the serial data output signal <NUM>) to one or more commands received in the command phase <NUM>(<NUM>) of the first frame <NUM>(<NUM>) (e.g., in a serial data input signal <NUM>). As part of the one or more status responses in the second frame <NUM>(<NUM>), the peripheral device interface can inform the master controller of any faults that occur after the beginning of the first frame <NUM>(<NUM>) and before the beginning of the second frame <NUM>(<NUM>). Thus, the latency of fault reporting and reaction to faults is dependent on the frequency of frame transmission.

Between the first frame <NUM>(<NUM>) and the second frame <NUM>(<NUM>), a chip select signal <NUM> can remain high, indicating that communications with the peripheral device interface are not enabled. A clock signal <NUM> can continue to periodically vary between a high value and a low value to provide timing for other peripheral device interfaces that share the same clock bus. A serial data input signal <NUM> and a serial data output signal <NUM> can also be used for communications between the master controller and other peripheral device interfaces that are enabled using chip select lines that correspond to the other peripheral device interfaces. During the intervening time period, the peripheral device interface is unable to communicate with the master controller via the serial communication bus.

In a functional safety system, the maximum acceptable system level response time for reacting to a fault can be defined as a fault tolerant time interval (FTTI). Each peripheral device interface in the overall system is allocated a particular amount of time (and a particular periodic or intermittent frame slot) for communicating with the master controller, and the amount of time available to communicate to the master controller can be defined as a fault detection time interval (FDTI). For example, if a fault occurs during transmission of the first frame <NUM>(<NUM>), the fault detection time interval may represent the amount of time between occurrence or detection of the fault at the peripheral device and the command phase <NUM>(<NUM>) of the second frame <NUM>(<NUM>), when the fault can be reported to the master controller. The overall system can also have a fault reaction time interval (FRTI) that represents the amount of time needed to react to and address a fault once the fault is communicated to the master controller. To satisfy the maximum acceptable system level response time, the fault detection time interval plus the fault reaction time interval should be less than the fault tolerant time interval (i.e., FDTI + FRTI < FTTI). If the fault reaction time interval is relatively predictable and consistent, then satisfying the maximum acceptable system level response time may necessitate decreasing the fault detection time interval, which can be accomplished by increasing the frequency of polling of fault flags through serial communication. Such polling of fault flags, for example, can be performed through enabling communications with the peripheral device interface (e.g., using the chip select signal <NUM>), which allows the peripheral device interface to transmit status data including fault reporting data (e.g., in the command phase <NUM>(<NUM>) of the second frame <NUM>(<NUM>) for faults that occur after the beginning of the first frame <NUM>(<NUM>)). In other words, higher frequency polling can be accomplished by decreasing the amount of time between the first frame <NUM>(<NUM>) and the second frame <NUM>(<NUM>). Higher frequency polling, however, places an additional burden on software and serial communications in the overall system.

<FIG> shows a waveform timing diagram <NUM> for a frame <NUM> of a serial peripheral interface (SPI) bus in accordance with an alternative implementation of communications between a master controller and a peripheral device. Analogous to the frame <NUM> of <FIG>, the frame <NUM> includes multiple timeslots <NUM>, a command phase <NUM> that begins with a first timeslot <NUM>(<NUM>) and ends with an eighth timeslot <NUM>(<NUM>), and a data phase <NUM> that begins with a ninth timeslot <NUM>(<NUM>) and ends with an <NUM>th timeslot <NUM>(<NUM>). Communications between the peripheral device interface and the master controller are enabled using a chip select signal <NUM>, timeslots <NUM> are defined by a clock signal <NUM>, communications from the master controller to the peripheral device interface are transmitted in a serial data input signal <NUM>, and communications from the peripheral device interface to the master controller are transmitted in a serial data output signal <NUM>. Each timeslot <NUM> of the command phase <NUM> includes a command bit <NUM> of the serial data input signal <NUM> and a status bit <NUM> of the serial data output signal <NUM>, and each timeslot <NUM> of the data phase <NUM> includes a master data bit <NUM> of the serial data input signal <NUM> and a peripheral data bit <NUM> of the serial data output signal <NUM>.

Differing from the example frame <NUM> of <FIG>, however, the example frame <NUM> includes a shorter <NUM>-bit CRC phase <NUM> that follows the command phase <NUM> and the data phase <NUM>, beginning with a <NUM>th timeslot <NUM>(<NUM>) and ending with a <NUM>th timeslot <NUM>(<NUM>). The example frame <NUM> also includes a <NUM>-bit reserved phase <NUM> in timeslots <NUM>(<NUM>) and <NUM>(<NUM>) and a <NUM>-bit fault status phase <NUM> in timeslots <NUM>(<NUM>) and <NUM>(<NUM>). The reserved phase <NUM> follows the CRC phase <NUM> and includes reserved bits <NUM>. The fault status phase <NUM> follows the reserved phase <NUM> and includes additional reserved bits <NUM> in the serial data input signal <NUM>, and a fault bit <NUM> and a fault parity bit <NUM> in the serial data output signal <NUM>. The fault bit <NUM> can be set to indicate whether a fault occurred during transmission of the frame <NUM>. For example, the fault bit <NUM> can be a flag, where a value of <NUM> indicates that a fault is detected and a value of <NUM> indicates that no fault is detected (or vice versa). The fault parity bit <NUM> can be a redundant fault bit, a parity bit for the frame <NUM> or a portion of the frame <NUM> (e.g., based on which the value of the fault bit <NUM> can be confirmed if there is an error in receiving the fault bit), or can otherwise provide some redundancy for protecting against communication errors.

In some implementations, one or more of the following additional or alternative features can be included. The fault bit <NUM> can be used to indicate whether a communication fault is detected in the frame <NUM> (e.g., bits are missing from the transmission, an unrecognized value is received, or the CRC value indicates an error that cannot be corrected), a diagnostic error is detected in the peripheral device (e.g., a sensor, power management component, or driver has an error condition), or both (e.g., a fault flag is set if either a communication fault or diagnostic fault is detected). The frame <NUM> can include redundant fault bits <NUM> and fault parity bits <NUM> (e.g., instead of the reserved bits <NUM> in the reserved phase <NUM>). The fault status phase <NUM> can encode additional information, such as the type of fault that is detected (e.g., missing bits or a CRC error). The fault parity bit <NUM> or the CRC phase <NUM> can be omitted. In some implementations, the command phase <NUM>, the data phase <NUM>, and/or the CRC phase <NUM> are not sequential but are instead interleaved (e.g., the frame <NUM> includes alternating status bits <NUM> and data bits <NUM>). Detection of a fault during the frame <NUM> can include situations where a fault occurs before the start of the frame <NUM> (e.g., prior to the first timeslot <NUM>(<NUM>)) but the fault is not recognized by the peripheral device until after the start of the frame <NUM> or after the values of the status bits <NUM> are placed in a buffer for transmission (e.g., the existence of the fault is not identified in time to indicate the fault in the command phase <NUM>).

By appending a fault flag at the end of the frame, the latency of fault detection by the master controller and in the overall system can be reduced by one frame. As a result, the time between transmissions can potentially be extended (e.g., if communications with a peripheral device interface would be enabled every five microseconds in the implementation illustrated in <FIG> and <FIG>, communications may be reduced to only every ten microseconds in the implementation of <FIG>). In addition, faults that occur during transmission of a frame can be immediately addressed, and the master controller can take suitable actions to respond to the fault. For example, the master controller, in some implementations, can enable communications with the peripheral device interface out of an ordinary periodic sequence to more quickly receive status data that provides more details about the nature of the fault or to resend the frame in which the error occurred (e.g., the fault bit serves as an immediate interrupt to typical operations). Appending the fault bit can thus avoid a potential need to add a separate interrupt pin to the master controller and peripheral device circuitry. The fault status phase <NUM> does not necessarily communicate as much information about a fault as can be communicated in the command phase <NUM>. Rather, the fault status phase <NUM> can, in some implementations, simply indicate that a fault is detected, and additional information about the fault can be communicated in a subsequent frame <NUM>.

<FIG> shows a waveform timing diagram <NUM> for a frame <NUM> of a serial peripheral interface (SPI) bus in accordance with an alternative implementation of communications between a master controller and a peripheral device. Analogous to the frame <NUM> of <FIG>=5b, the frame <NUM> includes multiple timeslots <NUM>, a command phase <NUM> that begins with a first timeslot <NUM>(<NUM>) and ends with an eighth timeslot <NUM>(<NUM>), a data phase <NUM> that begins with a ninth timeslot <NUM>(<NUM>) and ends with an <NUM>th timeslot <NUM>(<NUM>), and a CRC phase <NUM> that follows the command phase <NUM> and the data phase <NUM>, beginning with a <NUM>th timeslot <NUM>(<NUM>) and ending with a <NUM>th timeslot <NUM>(<NUM>). Communications between the peripheral device interface and the master controller are enabled using a chip select signal <NUM>, timeslots <NUM> are defined by a clock signal <NUM>, communications from the master controller to the peripheral device interface are transmitted in a serial data input signal <NUM>, and communications from the peripheral device interface to the master controller are transmitted in a serial data output signal <NUM>. Each timeslot <NUM> of the command phase <NUM> includes a command bit <NUM> of the serial data input signal <NUM> and a status bit <NUM> of the serial data output signal <NUM>, and each timeslot <NUM> of the data phase <NUM> includes a master data bit <NUM> of the serial data input signal <NUM> and a peripheral data bit <NUM> of the serial data output signal <NUM>.

Differing from the example frame <NUM> of <FIG>, however, the example frame <NUM> includes a <NUM>-bit frame and device status phase <NUM> that begins with a <NUM>st timeslot <NUM>(<NUM>) and ends with a <NUM>th timeslot <NUM>(<NUM>). The frame and device status phase <NUM> follows the CRC phase <NUM> and includes reserved bits <NUM> in the serial data input signal <NUM>, a communication fault bit <NUM>, a communication fault parity bit <NUM>, a device fault bit <NUM>, and a device fault parity bit <NUM> in the serial data output signal <NUM>. The communication fault bit <NUM> can be set to indicate whether a communication fault occurred during transmission of the frame <NUM>, and the device fault bit <NUM> can be set to indicate whether a diagnostic fault occurred during transmission of the frame <NUM>. For example, the communication fault bit <NUM> and the device fault bit <NUM> can each be a flag, where a value of <NUM> indicates that a fault is detected and a value of <NUM> indicates that no fault is detected (or vice versa). The communication fault parity bit <NUM> and the device fault parity bit <NUM> can each be a redundant fault bit or can otherwise provide some other type of redundancy for protecting against communication errors.

Compared to the example frame <NUM> of <FIG>, the example frame <NUM> of <FIG> can further enable the peripheral device interface to separately communicate whether a detected fault is a communication fault or a diagnostic fault (or both), which allows the master controller to respond accordingly. In some implementations, the CRC phase <NUM> can be omitted or the CRC phase <NUM> can follow the frame and device status phase <NUM>. The fault status phase <NUM> can alternatively include a different number of timeslots than described in the examples of <FIG> and <FIG>. In some implementations, the fault status phase <NUM> can communicate other types of limited information about the fault while relying upon a subsequent frame <NUM> to communicate additional information. For example, the fault status phase <NUM> can include a flag that indicates whether a fault is detected and one, two, or more bits that distinguish between different categories of faults (e.g., a two-bit code can be used to distinguish between a CRC error, another type of communication error, and two different categories of diagnostic faults).

<FIG> shows a waveform timing diagram <NUM> for a sequential pair of frames <NUM>(<NUM>) and <NUM>(<NUM>) of the serial peripheral interface (SPI) bus described in connection with <FIG>. The first frame <NUM>(<NUM>) is not necessarily first in a sequence of frames but can be a frame n in a sequence of frames sent between the master controller and a particular peripheral device interface, while the second frame <NUM>(<NUM>) is the next serial frame n+<NUM> in the sequence of frames sent between the master controller and the particular peripheral device interface. The first frame <NUM>(<NUM>) includes a command phase <NUM>(<NUM>), a data phase <NUM>(<NUM>), a CRC phase <NUM>(<NUM>), a reserved phase <NUM>(<NUM>), and a fault status phase <NUM>(<NUM>). The command phase <NUM>(<NUM>) of the first frame <NUM>(<NUM>) can include one or more status responses encoded in a serial data output signal <NUM> to one or more commands received in a previous frame. The fault status phase <NUM>(<NUM>) of the first frame <NUM>(<NUM>) can include fault flags for communication faults and/or diagnostic faults that occur and/or are detected during the first frame <NUM>(<NUM>).

The second frame <NUM>(<NUM>) includes a command phase <NUM>(<NUM>), a data phase <NUM>(<NUM>), a CRC phase <NUM>(<NUM>), a reserved phase <NUM>(<NUM>), and a fault status phase <NUM>(<NUM>). The command phase <NUM>(<NUM>) of the second frame <NUM>(<NUM>) can include one or more status responses encoded in the serial data output signal <NUM> to one or more commands received in the command phase <NUM>(<NUM>) of the first frame <NUM>(<NUM>) in a serial data input signal <NUM>. The fault status phase <NUM>(<NUM>) of the second frame <NUM>(<NUM>) can include fault flags for communication faults and/or diagnostic faults that occur and/or are detected during the second frame <NUM>(<NUM>). As part of the one or more status responses in the second frame <NUM>(<NUM>), the peripheral device interface can inform the master controller of any faults that occur after the end of the first frame <NUM>(<NUM>) and before the beginning of the second frame <NUM>(<NUM>). Thus, the latency of fault reporting and reaction to faults is reduced compared to the waveform timing diagram of <FIG>. An analogous result is also achieved using the serial peripheral interface (SPI) bus described in connection with <FIG>.

In some implementations, when a fault flag in the fault status phase <NUM>(<NUM>) of the first frame <NUM>(<NUM>) includes a fault flag is set to indicate that a fault is detected during sending of the first frame <NUM>(<NUM>), communication of the second frame <NUM>(<NUM>) can be enabled sooner than would otherwise occur if the fault flag is not set. Communication of the second frame <NUM>(<NUM>) can be enabled by the master controller setting a low level of the chip select signal <NUM> before the master controller would enable communication of the second frame <NUM>(<NUM>) if the fault flag is not set. Thus, the interval between the first frame <NUM>(<NUM>) and the second frame <NUM>(<NUM>) can differ depending on whether the fault flag is set. For example, communication of the second frame <NUM>(<NUM>) can be enabled relatively immediately (e.g., as soon as a serial communication frame between the master controller and another peripheral device interface is complete), as soon as an otherwise unused frame period is available on the serial bus, on a priority basis (e.g., by dynamically or statically ranking priority levels of communication for different peripheral devices depending on their respective functional safety importance and/or fault status), or at an otherwise reduced interval (e.g., a <NUM> microsecond interval where the standard interval without a fault indication is <NUM> microseconds). In some cases, the master controller can control overall communications with all of the peripheral devices that share a serial data bus such that a prioritization of communication of the second frame <NUM>(<NUM>) for a particular peripheral device can result in an extension of a communication interval (e.g., <NUM> microseconds instead of <NUM> microseconds) for one or more of the other peripheral devices that are considered lower priority.

<FIG> depicts an illustration of an example peripheral device circuit <NUM> that can implement the functional safety techniques described in this specification. The peripheral device circuit <NUM> includes an interface circuit <NUM>, an output driver circuit <NUM>, and an input receiver circuit <NUM>. The interface circuit <NUM> includes a Circuit Select Not (nCS) pin <NUM>, a clock (CLK) pin <NUM>, a serial data input (SDI) pin <NUM>, and a serial data output (SDO) pin <NUM> through which the corresponding serial communication signals of <FIG> can be communicated between the peripheral device interface and the master controller. The peripheral device circuit <NUM> can also include additional pins, including a voltage supply (VDD) pin <NUM>, a ground (GND) pin <NUM>, a first input/output (IO1) pin <NUM>, and a second input/output (IO2) pin <NUM>. The output driver circuit <NUM> can include a first output (OUTA) pin <NUM> and a second output (OUTB) pin <NUM>, and the input receiver circuit <NUM> can include a first input (INA) pin <NUM> and a second input (INB) pin <NUM>. In the context of the first output pin <NUM>, the second output pin <NUM>, the first input pin <NUM>, and the second input pin <NUM>, input and output refer to data sent to and received from, respectively, a connected component. Thus, output data sent via the first output pin <NUM>, the second output pin <NUM> may be sent to the connected component in response to input data received via the serial data input pin <NUM>, and input data received via the first input pin <NUM>, and the second input pin <NUM> may be used by the interface circuit <NUM> to generate output data sent via the serial data output pin <NUM>. Implementations may not include all of the illustrated pins, and/or other pins may also be included. One or more of the pins can be connected to, or adapted to connect to, a serial communication bus. In some implementations, one or more of the pins (e.g., the input and/or output pins <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>) can be connected to, or adapted to connect to, other types of communication buses or wires (e.g., a parallel communication bus or an analog transmission wire).

The interface circuit <NUM> includes control logic <NUM>, an input register <NUM>, an output register <NUM>, and a fault flag register <NUM>. In some implementations, the input register <NUM> can include multiple registers for storing different portions of incoming data. The output register <NUM> and the fault flag register can also be divided into additional registers or combined into a single register. The control logic <NUM> controls operation of the interface circuit <NUM> through instructions embedded in the interface circuit <NUM> or stored in a register. Input signals received via the serial data input pin <NUM> can be stored in the input register <NUM> and are read and processed by the control logic <NUM> to, for example, control the output driver <NUM> and to cause the interface circuit <NUM> to perform communication operations in response to commands and data in a serial input frame. The control logic <NUM> can also control operation of the input receiver and process data received by the input receiver <NUM> (e.g., from a connected sensor or other component) to store bits in the output register <NUM>, which can be used to generate an output serial data frame to be transmitted via the serial data output pin <NUM>. The bits stored in the output register <NUM> can include information regarding faults detected before bits for an output serial data frame are stored in the output register <NUM> and/or before transmission of the output serial data frame begins. The control logic <NUM> can also generate the output serial data frame, causing the bits in the output register <NUM> to be transmitted in the output serial data frame in response to an enable signal on the Circuit Select Not pin <NUM> and a clock signal on the clock pin <NUM>.

If a fault is detected during transmission of the output serial data frame, the control logic <NUM> can set one or more bits in the fault flag register <NUM> to a value or values indicating a fault. If no fault is detected, the one or more bits are set to a value or values indicating no fault is detected. The control logic <NUM> can cause the bits in the fault flag register <NUM> to be transmitted as part of the output serial data frame during which the fault is detected. Accordingly, the output serial data frame can include an indication of a fault that occurs during transmission of the output serial data frame.

The peripheral device circuit <NUM> can be an integrated circuit that connects to a sensor, a power stage, a power supply, or another component. The first and second output pins <NUM> and <NUM> can be used to communicate instructions (e.g., encoded commands) and other data to the connected component, and the first and second input pins <NUM> and <NUM> can be used to receive status information and other data from the connected component. In some implementations, the input/output pins <NUM> and <NUM> can be used to communicate selected data (e.g., different data than is communicated via the interface circuit <NUM>) with other components in the overall system. For example, if the connected component is a sensor, sensor parameter data can be received via the input/output pins <NUM> and <NUM>, processed or managed by the output driver circuit <NUM>, and sent to the sensor via the output pins <NUM> and <NUM>. Sensor status and analog sensor detection levels can be received via the input pins <NUM> and <NUM>, processed or managed by the input receiver circuit <NUM>, and sent to other components via the input/output pins <NUM> and <NUM>.

Although the description above uses a serial peripheral interface (SPI) as an example, the techniques described in this specification can alternatively be used in other types of communication protocols and systems. For example, the techniques can be used in connection with an I<NUM>C communication bus, an I<NUM>S communication bus, or a universal asynchronous receiver/transmitter. In some implementations, instead of using separated serial data input and serial data output communication lines, a one-way communication followed by reverse direction on single data communication line can be used. In a one-way communication scenario, the fault flag can be appended to a data frame being sent by a component to a microcontroller to identify a fault detected during sending of the data frame. More than one input and output communication line can also be used to, for example, increase data rates. In some implementations, addressing of individual components can be used instead of an enable pin. Thus, an enable pin can be omitted in other situations (e.g., point-to-point communications). A clock pin can also be omitted (e.g., for at least some asynchronous serial communication protocols).

<FIG> is a flow diagram of a process <NUM> for communicating fault data in a functional safety system. Status bits and data bits are stored in a register at <NUM>. The status bits can include information about faults detected before the data frame is sent. The data bits can include information from a sensor, power management device, driver, or other component. Sending of a data frame between a microprocessor and a component is initiated at <NUM>. The data frame can include commands, status data (e.g., the status bits), and operational data (e.g., the data bits, diagnostic data, sensor data, power data, or other types of data). The data frame can be a data frame in a sequence of intermittent data frames communicated on a serial data bus.

A fault is detected by the component during sending of the data frame at <NUM>. For example, the fault can be detected after setting the status bits and data bits in the register or after transmitting at least one status bit of the data frame. The fault can be a communication fault relating to the data frame (or, in some cases, a previous data frame) or a diagnostic fault relating to the component or the function or operation of the component. In response to detecting the fault, a fault flag is set in a register at <NUM> and transmitted before the end of the data frame at <NUM>. The fault flag is included in the data frame after other data in the data frame. For example, the fault flag can be included at or towards the end of the data frame and/or after status data that includes information about faults detected either before the beginning of the data frame or before sending of the status data. The fault flag thus includes information about faults that are not indicated in the status data because, for example, the faults are detected after the status data is latched or sent. In addition, the fault flag can include different data than is included in the status data. For example, the fault flag can simply indicate the presence of a fault without communicating the type of fault, while the status data includes information about the type of fault, with or without a separate flag indicating the presence of a fault.

The fault flag is received (e.g., by the microprocessor) at <NUM>. In response to the fault flag, actions to address the fault are initiated at <NUM>. For example, the microprocessor, in response to receiving the fault flag, can initiate a system or communication interrupt of normal operations and can enable another data frame to be communicated between the microprocessor and the component to obtain additional information about the fault. The microprocessor can also (or alternatively) initiate other operations intended to correct the fault or otherwise react to or address the fault before a time that a next data frame between the microprocessor and the component (e.g., that could otherwise be used to identify the fault) would have otherwise been sent absent receipt of the fault flag. For example, the data frame can be part of a periodic sequence of data frames sent between the microprocessor and the component at a regular interval, and the microprocessor can, in response to the fault flag, initiate a subsequent communication with the component or perform some other corrective action before the regular interval elapses.

Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures described in this specification and their structural equivalents, or in combinations of one or more of them. Implementations of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions tangibly stored on a computer readable storage device for execution by, or to control the operation of, data processing apparatus. In addition, the one or more computer program products can be tangibly encoded in a propagated signal, which is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a computer. The computer readable storage device can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, or a combination of one or more of them.

A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, subprograms, or portions of code).

Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. Moreover, a computer can be embedded in another device, e.g., a vehicle, a mobile telephone, mobile device, a personal digital assistant (PDA), a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of nonvolatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CDROM and DVD-ROM disks.

Similarly, while operations are depicted in the drawings in a particular order, this does not require that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the implementations described above does not require such separation in all implementations, and the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Claim 1:
An apparatus (<NUM>) comprising:
a serial output communication pin (<NUM>); and
an interface circuit (<NUM>) communicably connected to the serial output communication pin (<NUM>) and adapted to intermittently send an output serial data frame (<NUM>) to a controller (<NUM>) via the serial output communication pin (<NUM>), with each output serial data frame (<NUM>) including a status phase (<NUM>) and a data phase (<NUM>) followed by at least one fault bit (<NUM>),
characterized in that:
the at least one fault bit (<NUM>) indicates whether a fault is detected during sending of the output serial data frame (<NUM>).