Patent Description:
The present disclosure relates generally to serial communication over a shared serial bus and, more particularly, to providing feedback on a shared bus.

Mobile communication devices may include a variety of components including circuit boards, integrated circuit (IC) devices and/or System-on-Chip (SoC) devices. The components may include processing devices, user interface components, storage and other peripheral components that communicate through a shared data communication bus, which may include a multi-drop serial bus or a parallel bus. General-purpose serial interfaces known in the industry include the Inter-Integrated Circuit (I2C or I<NUM>C) serial interface and its derivatives and alternatives.

The Mobile Industry Processor Interface (MIPI) Alliance defines standards for the Improved Inter-Integrated Circuit (I3C) serial interface, the Radio Frequency Front-End (RFFE) interface, the System Power Management Interface (SPMI) and other interfaces. These interfaces may be used to connect processors, sensors and other peripherals, for example, through a multi-drop serial bus. In some interfaces, multiple bus masters are coupled to the serial bus such that two or more devices can serve as bus master for different types of messages transmitted on the serial bus. SPMI protocols define a hardware interface that may be implemented between baseband or application processors and peripheral components. In some instances, SPMI protocols are implemented to support power management operations within a device.

A multi-drop serial bus may be capable of supporting large numbers of devices that implement increasingly higher-speed, more complex applications, and new protocols are being developed to support such advanced applications. There is need to support legacy devices when new protocols are implemented.

Attention is drawn to document <CIT> which relates to systems, methods, and apparatus for communicating datagrams over a serial communication link. A transmitting device generates an address field in a datagram, sets a value of at least one bit in the address field to indicate a number of bytes of data associated with a data frame of the datagram, generates the data frame in the datagram, the data frame including the number of bytes of data, and sends the datagram to a receiving device. A receiving device receives a datagram from a transmitting device, decodes an address field of the datagram to detect a number of bytes of data included in a data frame of the datagram based on a value of at least one bit in the address field, and decodes the data frame to recover the detected number of bytes of data.

Further embodiments are defined in the appended dependent claims. Certain aspects of the disclosure relate to systems, apparatus, methods and techniques that can enable devices coupled to a serial bus to provide feedback that includes acknowledgement of transmissions over the serial bus. According to certain aspects, existing bus protocols can be leveraged to implement a feedback mechanism while providing for coexistence with conventional slave devices. The bus may be operated in accordance with an SPMI protocol, or another protocol usable on a serial bus.

Several aspects of the invention will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as "elements").

Devices that include SoC and other IC devices often employ a shared communication interface that may include a serial bus or other data communication link to connect different devices. In one example, a multi-drop serial bus may be implemented to interconnect processors with modems and other peripherals. The serial bus and other data communication link may be operated in accordance with multiple standards or protocols defined. For example, the serial bus may be operated in accordance with an I2C, I3C, SPMI, and/or RFFE protocol, or another protocol that may be configured for half-duplex operation. Increased functionality and complexity of operations involving devices coupled to serial buses, together with the use of greater numbers of peripherals, radiofrequency front-end devices and/or sensors device in support of complex applications requires updates to existing bus protocols that include new features that were undefined in earlier versions of the bus protocols.

Certain aspects of the disclosure relate to the provision of feedback capability for devices configured to provide feedback in accordance with one version of the SPMI specification when such devices are coupled to a serial bus operated in accordance with a different version of the SPMI specification that does not support feedback.

In one example, an apparatus includes an interface circuit adapted to couple the apparatus to a serial bus, and a processor. The processor may be configured to receive a write command from the serial bus, where the write command is received in a datagram and configured in accordance with an SPMI protocol, write a data byte received in a first data frame of the datagram to a register address identified by the datagram, and use a second data frame of the datagram to provide feedback regarding the datagram, by driving a data line of the serial bus to provide a negative acknowledgement during the second data frame when a transmission error is detected in the datagram, and refraining from driving the data line of the serial bus during the second data frame when no transmission error is detected in the datagram, thereby providing an acknowledgement of the datagram.

Certain aspects disclosed herein are described with reference to a serial bus operated in accordance with SPMI protocols. However, certain concepts may be equally applicable to RFFE protocols, I3C protocols, I2C protocols, and/or or another bus protocol. Certain aspects are applicable to a serial bus operated in half-duplex mode or full-duplex mode. Certain aspects are applicable to multipoint interfaces and/or interfaces operated in point-to-point mode.

According to certain aspects, a serial data link may be used to interconnect electronic devices that are subcomponents of an apparatus such as a cellular phone, a smart phone, a session initiation protocol (SIP) phone, a laptop, a notebook, a netbook, a smartbook, a personal digital assistant (PDA), a satellite radio, a global positioning system (GPS) device, a smart home device, intelligent lighting, a multimedia device, a video device, a digital audio player (e.g., MP3 player), a camera, a game console, an entertainment device, a vehicle component, a wearable computing device (e.g., a smart watch, a health or fitness tracker, eyewear, etc.), an appliance, a sensor, a security device, a vending machine, a smart meter, or any other similar functioning device.

<FIG> illustrates an example of an apparatus <NUM> that may employ a data communication bus. The apparatus <NUM> may include a processing circuit <NUM> having multiple circuits or devices <NUM>, <NUM> and/or <NUM>, which may be implemented in one or more ASIC devices or in a System-on-chip (SoC) device. In one example, the apparatus <NUM> may be configured for use as a communication device and the processing circuit <NUM> may include a processing device provided in an ASIC <NUM>, one or more peripheral devices <NUM>, and a transceiver <NUM> that enables the apparatus to communicate through an antenna <NUM> with a radio access network, a core access network, the Internet and/or another network.

The ASIC <NUM> may have one or more processors <NUM>, one or more modems <NUM>, on-board memory <NUM>, a bus interface circuit <NUM> and/or other logic circuits or functions. The processing circuit <NUM> may be controlled by an operating system that provides an application programming interface (API) layer that enables the one or more processors <NUM> to execute software modules residing in the on-board memory <NUM> or other processor-readable storage <NUM> provided on the processing circuit <NUM>. The software modules may include instructions and data stored in the on-board memory <NUM> or processor-readable storage <NUM>. The ASIC <NUM> may access its on-board memory <NUM>, the processor-readable storage <NUM>, and/or storage external to the processing circuit <NUM>. The on-board memory <NUM>, the processor-readable storage <NUM> may include read-only memory (ROM) or random-access memory (RAM), electrically erasable programmable ROM (EEPROM), flash cards, or any memory device that can be used in processing systems and computing platforms. The processing circuit <NUM> may include, implement, or have access to a local database or other parameter storage that can maintain operational parameters and other information used to configure and operate the apparatus <NUM> and/or the processing circuit <NUM>. The local database may be implemented using registers, a database module, flash memory, magnetic media, EEPROM, soft or hard disk, or the like. The processing circuit <NUM> may also be operably coupled to external devices such as the antenna <NUM>, a display <NUM>, operator controls, such as switches or buttons <NUM>, <NUM> and/or an integrated or external keypad <NUM>, among other components. A user interface module may be configured to operate with the display <NUM>, external keypad <NUM>, etc. through a dedicated communication link or through one or more serial data interconnects.

The processing circuit <NUM> may include or be coupled to one or more buses 118a, 118b, <NUM> that enable certain devices <NUM>, <NUM>, and/or <NUM> to exchange messages and other information. In one example, the ASIC <NUM> may have a bus interface circuit <NUM> that includes a combination of circuits, counters, timers, control logic and other configurable circuits or modules. In one example, the bus interface circuit <NUM> may be configured to operate in accordance with communication specifications or protocols. The processing circuit <NUM> may include or control a power management function that configures and manages the operation of the apparatus <NUM>.

<FIG> illustrates certain aspects of an apparatus <NUM> that includes multiple devices <NUM>, and <NUM><NUM>-<NUM>N coupled to a serial bus <NUM>. The devices <NUM> and <NUM><NUM>-<NUM>N may be implemented in one or more semiconductor IC devices, such as an application processor, SoC or ASIC. In various implementations the devices <NUM> and <NUM><NUM>-<NUM>N may include, support or operate as a modem, a signal processing device, a display driver, a camera, a user interface, a sensor, a sensor controller, a media player, a transceiver, RFFE devices, and/or other such components or devices. In some examples, one or more of the slave devices <NUM><NUM>-<NUM>N may be used to control, manage or monitor a sensor device. Communication between devices <NUM> and <NUM><NUM>-<NUM>N over the serial bus <NUM> is controlled by a bus master <NUM>. Certain types of bus can support multiple bus masters <NUM>.

In one example, a master device <NUM> may include an interface controller <NUM> that manages access to the serial bus, configures dynamic addresses for slave devices <NUM><NUM>-<NUM>N and/or causes a clock signal <NUM> to be transmitted on a clock line <NUM> of the serial bus <NUM>. The master device <NUM> may include configuration registers <NUM> or other storage <NUM>, and other control logic <NUM> configured to handle protocols and/or higher level functions. The control logic <NUM> may include a processing circuit such as a state machine, sequencer, signal processor or general-purpose processor. The master device <NUM> includes a transceiver <NUM> and line drivers/receivers 214a and 214b. The transceiver <NUM> may include receiver, transmitter and common circuits, where the common circuits may include timing, logic and storage circuits and/or devices. In one example, the transmitter encodes and transmits data based on timing in the clock signal <NUM> provided by a clock generation circuit <NUM>. Other timing clocks <NUM> may be used by the control logic <NUM> and other functions, circuits or modules.

At least one device <NUM><NUM>-<NUM>N may be configured to operate as a slave device on the serial bus <NUM> and may include circuits and modules that support a display, an image sensor, and/or circuits and modules that control and communicate with one or more sensors that measure environmental conditions. In one example, a slave device <NUM><NUM> configured to operate as a slave device may provide a control function, module or circuit <NUM> that includes circuits and modules to support a display, an image sensor, and/or circuits and modules that control and communicate with one or more sensors that measure environmental conditions. The slave device <NUM><NUM> may include configuration registers <NUM> or other storage <NUM>, control logic <NUM>, a transceiver <NUM> and line drivers/receivers 244a and 244b. The control logic <NUM> may include a processing circuit such as a state machine, sequencer, signal processor or general-purpose processor. The transceiver <NUM> may include receiver, transmitter and common circuits, where the common circuits may include timing, logic and storage circuits and/or devices. In one example, the transmitter encodes and transmits data based on timing in a clock signal <NUM> provided by clock generation and/or recovery circuits <NUM>. The clock signal <NUM> may be derived from a signal received from the clock line <NUM>. Other timing clock signals <NUM> may be used by the control logic <NUM> and other functions, circuits or modules.

The serial bus <NUM> may be operated in accordance with an I2C, I3C, RFFE, SPMI, C-PHY, D-PHY protocol or another suitable protocol. At least one device <NUM>, <NUM><NUM>-<NUM>N may be configured to selectively operate as either a master device or a slave device on the serial bus <NUM>. Two or more devices <NUM>, <NUM><NUM>-<NUM>N may be configurable to operate as a master device on the serial bus <NUM>.

In one example, the serial bus <NUM> may be operated in accordance with an I3C protocol. Devices that communicate using the I3C protocol can coexist on the same serial bus <NUM> with devices that communicate using I2C protocols. The I3C protocols may support different communication modes, including a single data rate (SDR) mode that is compatible with I2C protocols. High-data-rate (HDR) modes may provide a data transfer rate between <NUM> megabits per second (Mbps) and <NUM> Mbps, and some HDR modes may be provide higher data transfer rates. I2C protocols may conform to de facto I2C standards providing for data rates that may range between <NUM> kilobits per second (kbps) and <NUM> Mbps. I2C and I3C protocols may define electrical and timing aspects for signals transmitted on the <NUM>-wire serial bus <NUM>, in addition to data formats and aspects of bus control. In some aspects, the I2C and I3C protocols may define direct current (DC) characteristics affecting certain signal levels associated with the serial bus <NUM>, and/or alternating current (AC) characteristics affecting certain timing aspects of signals transmitted on the serial bus <NUM>. In some examples, a <NUM>-wire serial bus <NUM> transmits data on a data line <NUM> and a clock signal on the clock line <NUM>. In some instances, data may be encoded in the signaling state, or transitions in signaling state of the data line <NUM> and the clock line <NUM>.

In some conventional systems, multiple serial buses are provided to support demands for high data throughput, low latency, high bus availability and/or for other reasons. In some instances, multiple serial buses are used to alleviate issues cause by limited addressing capabilities of serial bus protocols. By way of example, <FIG> and <FIG> illustrate systems in which multiple serial buses may be employed to interconnect master and slave devices.

<FIG> illustrates an example of a system <NUM> that includes a serial bus that may be operated in accordance with an SPMI, or another bus protocol. In some implementations, SPMI protocols are used for power management control and the bus may be configured to support communication of commands used to cause circuits or functional components to reset, sleep, shutdown, wakeup, and so on. In some implementations, SPMI bus protocols may be used to implement a general-purpose communication link. In the illustrated example, a two-wire serial bus includes a first wire (SCLK <NUM>) that carries a clock signal and a second wire (SDATA <NUM>) that carries a data signal transmitted in accordance with timing provided by the clock signal. The serial bus may connect multiple slave devices, including application processors, modems, sensors, controllers etc. that can be configured to serve as a master device. For example, a power management integrated circuit (PMIC <NUM>) may be coupled to a serial bus that is operated in accordance with an SPMI protocol.

Devices may be coupled to the serial bus as a slave or master. In the example of a serial bus operated in accordance with an SPMI protocol, between one and four master devices <NUM>, <NUM> and up to <NUM> slave devices <NUM>, <NUM>, <NUM>, <NUM> may be coupled to the serial bus. SPMI protocols, support bus contention arbitration, request arbitration and group addressing. Slave devices <NUM>, <NUM>, <NUM>, <NUM> coupled to the serial bus devices may be required to acknowledge certain commands. A Bus Arbitration sequence is performed before transactions to allocate control of the serial bus to one master or to one slave when multiple devices are requesting access to the serial bus in order to send a command sequence. A request for access to the serial bus can be made when the bus is idle by driving SDATA <NUM> to a high signaling state while SCLK <NUM> is in a low signaling state. Certain slave devices are capable of requesting access to the serial bus.

During certain operations, SCLK <NUM> and/or SDATA <NUM> may be undriven and may be held in a signaling state by keeper circuit <NUM>, or by a pulldown circuit <NUM>. In one example, a keeper circuit <NUM> may be configured as a positive feedback circuit that drives SDATA <NUM> through a high impedance output, and receives feedback from SDATA <NUM> through a low impedance input. The keeper circuit <NUM> may be configured to maintain the last asserted voltage on SDATA <NUM>. The keeper circuit <NUM> can be easily overcome by a line driver in a master device <NUM>, <NUM> or a slave device <NUM>, <NUM>, <NUM>, <NUM>. In some instances, a pulldown circuit <NUM> (or pull-up circuit) may be used to maintain SCLK <NUM> and/or SDATA <NUM> in a desired signaling state. The illustrated pulldown circuit <NUM> can be activated to couple a pulldown resistor to a line of the serial bus.

Protocols that support communication over a multi-drop serial bus may define a datagram structure used to transmit command, control and data payloads within application-defined latency tolerances. Datagram structures for different protocols define certain common features, including addressing used to select devices to receive or transmit data, clock generation and management, interrupt processing and device priorities. In this disclosure, the example of SPMI protocols is employed to illustrate certain aspects of the disclosure. However, the concepts disclosed herein are applicable to other serial bus protocols and standards.

<FIG> illustrates a datagram <NUM> and a corresponding timing diagram <NUM> for an Extended Register Write (ERW) command that may be transmitted over a serial bus. The datagram <NUM> may be transmitted by a device that wins bus arbitration during an arbitration sequence <NUM>. The datagram <NUM> commences with a two-bit sequence start condition (SSC <NUM>, <NUM>) followed by a four-bit slave address <NUM>, <NUM> or other device identifier. An <NUM>-bit command code <NUM>, <NUM> is provided with a parity bit. The command code <NUM><NUM> includes a byte count (BC[<NUM>:<NUM>]) that indicates the number of bytes to be written. The command code <NUM>, <NUM> is followed by an <NUM>-bit register address <NUM>, <NUM> and between one and sixteen frames of data <NUM>. The data may include at least a first data frame <NUM>. After transmission of a final data frame <NUM>, bus park signaling <NUM>, <NUM> is provided. The bus park signaling <NUM>, <NUM> is provided when the slave device initially drives SDATA low and then releases SDATA to an undriven state <NUM>, in which SDATA is held low by a keeper circuit, a pulldown circuit/resistance.

<FIG> illustrates a datagram <NUM> and a corresponding timing diagram <NUM> for an Extended Register Write Long (ERWL) command that may be transmitted over a serial bus. The datagram <NUM> may be transmitted by a device that wins bus arbitration during an arbitration sequence <NUM>. The datagram <NUM> commences with transmission of a two-bit sequence start condition (SSC <NUM>, <NUM>) followed by a four-bit slave address <NUM>, <NUM> or other device identifier. An <NUM>-bit command code <NUM>, <NUM> is provided with a parity bit. The command code <NUM>, <NUM> incudes a byte count (BC[<NUM>:<NUM>]) that indicates the number of bytes to be written. The command code <NUM>, <NUM> is followed by a <NUM>-bit register address <NUM>. The <NUM>-bit register address <NUM> may include an upper address byte <NUM> and a lower address byte <NUM>. Between one and eight frames of data <NUM> may be transmitted in the datagram <NUM>. The data <NUM> may include at least a first data frame <NUM>. After transmission of a final data frame <NUM>, bus park signaling <NUM>, <NUM> is transmitted.

Certain versions of SPMI specifications (which may be identified as SPMI <NUM>. x herein) do not include all of the features defined for later versions of the SPMI specifications (which may be identified as SPMI <NUM>. In one example, an acknowledgement feature defined for SPMI <NUM>. x is not available for use on a device operating in accordance with SPMI <NUM>. In some SPMI <NUM>. x implementations, an acknowledge/not acknowledge (ACK/NACK) bit may be transmitted at the end of a datagram, after first bus park signaling <NUM>, <NUM>, <NUM>, <NUM> and may be followed by second bus park signaling. When a Command Sequence that provides for an ACK/NACK bit is addressed to a single device using a unique slave identifier (USID) or a master identifier (MID), the addressed device may be configured to respond with an ACK/NACK bit value of 'b1 if the command sequence was received correctly. The addressed device may be configured to respond with an ACK/NACK bit value of 'b0 if the command sequence was received correctly. When a Command Sequence that provides for an ACK/NACK bit is addressed to a group of slave devices using a group slave identifier (GSID), an addressed device may be configured to maintain its line driver for SDATA in a high-impedance state if the command sequence was received correctly and a slave device may be configured to respond with an ACK/NACK value of 'b1 only if an error was detected in the command sequence. On a serial bus operated in accordance with SPMI protocols, SDATA is typically pulled low when all devices are in a high-impedance state.

Certain aspects of this disclosure relate to techniques that leverage existing bus protocols to expand the ability of devices to provide and receive feedback on data transmitted over a serial bus. In some examples, feedback includes an acknowledgement (ACK) that a command sequence that includes one or more data bytes has been received without apparent error. In some examples, feedback includes a negative acknowledgement (NACK) indicating an error associated with the reception of the command sequence. In some implementations, feedback can be enabled and supported when existing bus protocols do not provide a feedback mechanism by providing a dummy data byte and manipulating the byte count in the command sequence to ensure that a sufficient number of clock pulses are provided to accommodate transmission of the dummy data byte.

Certain aspects of this disclosure relate to a feedback mechanism that can be used when devices compliant with SPMI <NUM>. x are configured for use on a serial operated in accordance the SPMI <NUM>. In one aspect, the feedback mechanism does not impact the functionality of legacy devices, such as a PMIC <NUM> (see <FIG>) that supports SPMI <NUM>. In one example, a device that is compliant with SPMI <NUM>. x and configured according to certain aspects of this disclosure may support a feedback mechanism implemented using dummy data bytes and ERW and ERWL command sequences when operating on a serial bus in accordance with SPMI <NUM>. x bus where ACK/NACK cycle is not available.

<FIG> illustrates a first transaction that supports acknowledgements in accordance with certain aspects disclosed herein. In this example, acknowledgements are supported using an ERW command. A first timing diagram <NUM> illustrates certain portions of a conventional datagram that includes an ERW command frame <NUM> transmitted using SCLK <NUM> and SDATA <NUM>, and a second timing diagram <NUM> illustrates certain portions of a datagram that includes an ERW command frame <NUM> that has been configured in accordance with certain aspects disclosed herein.

According to certain aspects of the disclosure, feedback is provided in a datagram using a dummy data byte provided after the last valid data byte. A conventional device may be configured to ignore the dummy data byte. In both timing diagrams <NUM>, <NUM>, bus arbitration <NUM>, <NUM> precedes transmission of the ERW command frame <NUM>, <NUM>. The device that wins bus arbitration <NUM>, <NUM> transmits the ERW command frame <NUM>, <NUM>, which includes a target slave identifier, and the ERW command code. In the first timing diagram <NUM>, the ERW command code includes a byte count <NUM> (BC[<NUM>:<NUM>]) that is set to '<NUM>' indicating that one byte is to be written. The ERW command frame <NUM> is followed by an <NUM>-bit register address (shown as a compressed period <NUM>) followed by a single data byte <NUM>. Bus park signaling <NUM> indicates the end of the datagram.

In the second timing diagram <NUM>, the ERW command code includes a byte count <NUM> (BC[<NUM>:<NUM>]) that is set to '<NUM>' indicating to the transmitter that two data bytes are being transmitted, causing the transmitter to provide sufficient clock pulses for transmitting two bytes. A conventional receiving device may be configured to ignore the last data byte. A device that is configured to provide feedback, may be further configured in accordance with certain aspects of this disclosure to provide the feedback within the data frame corresponding to the dummy data byte <NUM>.

Continuing with the second timing diagram <NUM>, an <NUM>-bit register address (shown as a compressed section <NUM>) is transmitted after the ERW command frame <NUM>, followed by a data byte <NUM> for writing to the identified register address. The transmitter drives SDATA <NUM> to the low signaling state until the seventh clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>, at which point the transmitter provides bus park signaling <NUM>, releasing SDATA <NUM> and causing its SDATA line driver to enter a high-impedance state. The receiving device can then provide feedback in the form of an ACK/NACK bit <NUM> during the eighth clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>. When the ERW command frame <NUM> is addressed to a MID or USID, a receiving device drives SDATA <NUM> to the high signaling state to acknowledge successful receipt of the datagram and leaves SDATA <NUM> in the low signaling state when an error has been detected in the preceding data. When the ERW command frame <NUM> is addressed to a GSID, a receiving device maintains its SDATA line driver in a high-impedance state when the datagram is successfully received and drives SDATA <NUM> to the high signaling state to indicate an error has been detected in the datagram. SDATA <NUM> may be returned to the low signaling state during the ninth pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>, where the ninth pulse corresponds to a dummy parity bit. Bus park signaling <NUM> is then provided by releasing SDATA <NUM> and causing SDATA line drivers to enter a high-impedance state.

In the second timing diagram <NUM>, the device that wins bus arbitration <NUM>, <NUM> drives SDATA <NUM> for the duration of a transaction (Slave-<NUM><NUM>), commencing with the transmission of the ERW command frame <NUM> and continuing until the first bus park signaling <NUM>. The winning device hands over control of SDATA <NUM> by providing the first bus park signaling <NUM>. One or more devices targeted by the ERW command frame <NUM> actively drive SDATA <NUM> for a period <NUM> that begins during or after the first bus park signaling <NUM> and ends with second bus park signaling <NUM> upon completion of transmission of the dummy data byte <NUM>.

<FIG> illustrates a second transaction that supports acknowledgements in accordance with certain aspects disclosed herein. In this example, acknowledgements are supported using an ERWL command. A first timing diagram <NUM> illustrates certain portions of a conventional datagram that includes an ERWL command frame <NUM> transmitted using SCLK <NUM> and SDATA <NUM>, and a second timing diagram <NUM> illustrates certain portions of a datagram that includes an ERWL command frame <NUM> that has been configured in accordance with certain aspects disclosed herein.

According to certain aspects of the disclosure, feedback is provided in a datagram using a dummy data byte transmitted after the last valid data byte. A conventional device may be configured to ignore the dummy data byte. In both timing diagrams <NUM>, <NUM>, bus arbitration <NUM>, <NUM> precedes transmission of the ERWL command frame <NUM>, <NUM>. The device that wins bus arbitration <NUM>, <NUM> transmits the ERWL command frame <NUM>, <NUM>, which includes a target slave identifier, and the ERWL command code. In the first timing diagram <NUM>, the ERWL command code includes a byte count <NUM> (BC[<NUM>:<NUM>]) that is set to '<NUM>' indicating that one byte is to be written. The ERWL command frame <NUM> is followed by an <NUM>-bit register address (shown as a compressed period <NUM>) followed by a single data byte <NUM>. Bus park signaling <NUM> indicates the end of the datagram.

In the second timing diagram <NUM>, the ERWL command code includes a byte count <NUM> (BC[<NUM>:<NUM>]) that is set to '<NUM>' indicating to the transmitter that two data bytes are being transmitted, causing the transmitter to provide sufficient clock pulses for transmitting two bytes. A conventional receiving device may be configured to ignore the last data byte. A device that is configured to provide feedback, is further configured in accordance with certain aspects of this disclosure to provide the feedback within the data frame corresponding to the dummy data byte <NUM>.

Continuing with the second timing diagram <NUM>, after the ERWL command frame <NUM> an <NUM>-bit register address (shown as a compressed period <NUM>) is transmitted, followed by a data byte <NUM> for writing to the identified register address. The transmitter drives SDATA <NUM> to the low signaling state until the seventh clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>, at which point the transmitter provides bus park signaling <NUM> by releasing SDATA <NUM> and causing its SDATA line driver to enter a high-impedance state. The receiving device can then provide feedback in the form of an ACK/NACK bit <NUM> during the eighth clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>.

When the ERWL command frame <NUM> is addressed to a MID or USID, a receiving device drives SDATA <NUM> to the high signaling state to acknowledge successful receipt of the datagram, and leaves SDATA <NUM> in the low signaling state when an error has been detected in the preceding data. When the ERWL command frame <NUM> is addressed to a GSID, a receiving device maintains its SDATA line driver in a high-impedance state when the datagram is successfully received and drives SDATA <NUM> to the high signaling state to indicate an error has been detected in the datagram. SDATA <NUM> may be returned to the low signaling state during the ninth pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>, where the ninth pulse corresponds to a dummy parity bit. Bus park signaling <NUM> is then provided by releasing SDATA <NUM> and causing SDATA line drivers to enter a high-impedance state.

In the second timing diagram <NUM>, the device that wins bus arbitration <NUM>, <NUM> drives SDATA <NUM> for the duration of the transaction (Slave-<NUM><NUM>), commencing with the transmission of the ERWL command frame <NUM> and continuing until the first bus park signaling <NUM>. The winning device may handover control of SDATA <NUM> by providing the first bus park signaling <NUM>. One or more devices targeted by the ERWL command frame <NUM> may actively drive SDATA <NUM> for a period <NUM> that begins during or after the first bus park signaling <NUM> and ends with second bus park signaling <NUM> upon completion of transmission of the dummy data byte <NUM> when a negative acknowledgement is to be sent.

<FIG> illustrates a third transaction that supports acknowledgements in accordance with certain aspects disclosed herein. In this example, acknowledgements are supported using an ERW command. A first timing diagram <NUM> illustrates certain portions of a conventional datagram that includes an ERW command frame <NUM> transmitted using SCLK <NUM> and SDATA <NUM>, and a second timing diagram <NUM> illustrates certain portions of a datagram that includes an ERW command frame <NUM> that has been configured in accordance with certain aspects disclosed herein.

In the second timing diagram <NUM>, the ERW command code includes a byte count <NUM> (BC[<NUM>:<NUM>]) that is set to '<NUM>' indicating to the transmitter that two data bytes are being transmitted, causing the transmitter to provide sufficient clock pulses for transmitting two bytes. A conventional receiving device may be configured to ignore the last data byte. A device that is configured to provide feedback, is further configured in accordance with certain aspects of this disclosure to provide the feedback within the data frame corresponding to the dummy data byte <NUM>.

Continuing with the second timing diagram <NUM>, an <NUM>-bit register address (shown as a compressed section <NUM>) is transmitted after the ERW command frame <NUM>, followed by a data byte <NUM> for writing to the identified register address. In this example, early bus park signaling <NUM> is provided. The transmitter drives SDATA <NUM> to the low signaling state after the last bit of the parity bit of the data byte <NUM> has been transmitted, during the first clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>. The transmitter provides the bus park signaling <NUM> by releasing SDATA <NUM> and causing its SDATA line driver to enter a high-impedance state. SDATA <NUM> can remain in an undriven state <NUM>, being held low by a keeper circuit or a pull-down circuit. The receiving device can provide feedback in the form of an ACK/NACK bit <NUM> during the eighth clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>.

The receiving device may activate its driver at any point after the bus park signaling <NUM>. In one example, a receiving device that expects a slow line turnaround may activate its driver during the sixth clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>. In another example, a receiving device that expects a quick line turnaround may activate its driver during the seventh clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>.

When the ERW command frame <NUM> is addressed to a MID or USID, a receiving device may drive SDATA <NUM> to the high signaling state to acknowledge successful receipt of the datagram, and may leave SDATA <NUM> in the low signaling state when an error has been detected in the preceding data. When the ERW command frame <NUM> is addressed to a GSID, a receiving device may maintain its SDATA line driver in a high-impedance state when the datagram is successfully received and may drive SDATA <NUM> to the high signaling state to indicate an error has been detected in the datagram. SDATA <NUM> may be returned to the low signaling state during the ninth pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>, where the ninth pulse corresponds to a dummy parity bit. Bus park signaling <NUM> is then provided by releasing SDATA <NUM> and causing SDATA line drivers to enter a high-impedance state.

In the second timing diagram <NUM>, the device that wins bus arbitration <NUM>, <NUM> drives SDATA <NUM> for the duration of the transaction (Slave-<NUM><NUM>), commencing with the transmission of the ERW command frame <NUM> and continuing until the first bus park signaling <NUM>. The winning device hands over control of SDATA <NUM> by providing the first bus park signaling <NUM>. One or more devices targeted by the ERW command frame <NUM> actively drive SDATA <NUM> for a period <NUM> that begins during or after the first bus park signaling <NUM> and that ends with second bus park signaling <NUM> upon completion of transmission of the dummy data byte <NUM>.

<FIG> illustrates a fourth transaction that supports acknowledgements in accordance with certain aspects disclosed herein. In this example, acknowledgements are supported using an ERWL command. A first timing diagram <NUM> illustrates certain portions of a conventional datagram that includes an ERWL command frame <NUM> transmitted using SCLK <NUM> and SDATA <NUM>, and a second timing diagram <NUM> illustrates certain portions of a datagram that includes an ERWL command frame <NUM> that has been configured in accordance with certain aspects disclosed herein.

In the second timing diagram <NUM>, the ERWL command code includes a byte count <NUM> (BC[<NUM>:<NUM>]) that is set to '<NUM>' indicating to the transmitter that two data bytes are being transmitted, causing the transmitter to provide sufficient clock pulses for transmitting two bytes. A conventional receiving device may be configured to ignore the last data byte. A device that is configured to provide feedback, may be further configured in accordance with certain aspects of this disclosure to provide the feedback within the data frame corresponding to the dummy data byte <NUM>.

Continuing with the second timing diagram <NUM>, after the ERWL command frame <NUM> an <NUM>-bit register address (shown as a compressed period <NUM>) is transmitted, followed by a data byte <NUM> for writing to the identified register address. The transmitter drives SDATA <NUM> to the low signaling state after the last bit of the parity bit of the data byte <NUM> has been transmitted, during the first clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>. The transmitter provides bus park signaling <NUM> by releasing SDATA <NUM> and by causing its SDATA line driver to enter a high-impedance state. SDATA <NUM> can remain in an undriven state <NUM>, being held low by a keeper circuit or a pull-down circuit. The receiving device can provide feedback in the form of an ACK/NACK bit <NUM> during the eighth clock pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>.

When the ERWL command frame <NUM> is addressed to a MID or USID, a receiving device may drive SDATA <NUM> to the high signaling state to acknowledge successful receipt of the datagram, and may leave SDATA <NUM> in the low signaling state when an error has been detected in the preceding data. When the ERWL command frame <NUM> is addressed to a GSID, a receiving device may maintain its SDATA line driver in a high-impedance state when the datagram is successfully received and may drive SDATA <NUM> to the high signaling state to indicate an error has been detected in the datagram. SDATA <NUM> may be returned to the low signaling state during the ninth pulse transmitted on SCLK <NUM> for the dummy data byte <NUM>, where the ninth pulse corresponds to a dummy parity bit. Bus park signaling <NUM> is then provided by releasing SDATA <NUM> and causing SDATA line drivers to enter a high-impedance state.

Certain aspects of this disclosure provide means by which a device that is compliant or compatible with more recently published SPMI protocols and/or specifications can provide feedback in a dummy data byte. A Register-<NUM> write command directed to the receiving slave device may be used to configure the receiving device to handle the dummy data byte for feedback purposes. <FIG> illustrates a datagram structure <NUM> for a Register-<NUM> Write command in accordance with SPMI protocols. Register-<NUM> Write commands are transmitted in the shortest datagrams defined by SPMI protocols. The datagram structure <NUM> commences with transmission of a two-bit sequence start condition (SSC <NUM>) followed by a four-bit slave address <NUM> or other device identifier. The <NUM>-bit command code <NUM> is transmitted next. The <NUM>-bit command code <NUM> is the only currently-defined command code that has a most significant bit (MSB <NUM>) set to <NUM>. The command code <NUM> is followed by a parity bit <NUM> and bus park signaling <NUM>.

According to certain aspects disclosed herein, the Register-<NUM> Write command in SPMI and RFFE protocols may be adapted to configure slave devices that can support the dummy data byte feedback technique disclosed herein. In one example, the Register-<NUM><NUM> may be usable to enable up to four slave devices for dummy data byte feedback. In the illustrated example, each of the four least-significant bits <NUM> Register-<NUM><NUM> defines status of dummy data byte feedback support. When one of the four least-significant bits <NUM> is set to a first logic state, then dummy data byte feedback is enabled, and when set to a second logic state, dummy data byte feedback is disabled.

The response of the transmitting device to dummy data byte feedback may be determined at high level layers. For example, an application may determine an appropriate response. Dummy data byte feedback may be employed when a group identifier is transmitted in a write command. SDATA may be pulled and held to low signaling state when no device is actively driving the line. Any device that wishes to signal a negative acknowledgement may drive SDATA to a high signaling state.

Legacy devices are not be impacted by the dummy data byte feedback signaling since the legacy device can decode the proper number of clocks to monitor the transaction.

<FIG> is a diagram illustrating an example of a hardware implementation for an apparatus <NUM>. In some examples, the apparatus <NUM> may perform one or more functions disclosed herein. In accordance with various aspects of the disclosure, an element, or any portion of an element, or any combination of elements as disclosed herein may be implemented using a processing circuit <NUM>. The processing circuit <NUM> may include one or more processors <NUM> that are controlled by some combination of hardware and software modules. Examples of processors <NUM> include microprocessors, microcontrollers, digital signal processors (DSPs), SoCs, ASICs, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, sequencers, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functionality described throughout this disclosure. The one or more processors <NUM> may include specialized processors that perform specific functions, and that may be configured, augmented or controlled by one of the software modules <NUM>. The one or more processors <NUM> may be configured through a combination of software modules <NUM> loaded during initialization, and further configured by loading or unloading one or more software modules <NUM> during operation.

In the illustrated example, the processing circuit <NUM> may be implemented with a bus architecture, represented generally by the bus <NUM>. The bus <NUM> may include any number of interconnecting buses and bridges depending on the specific application of the processing circuit <NUM> and the overall design constraints. The bus <NUM> links together various circuits including the one or more processors <NUM>, and storage <NUM>. Storage <NUM> may include memory devices and mass storage devices, and may be referred to herein as computer-readable media and/or processor-readable media. The bus <NUM> may also link various other circuits such as timing sources, timers, peripherals, voltage regulators, and power management circuits. A bus interface <NUM> may provide an interface between the bus <NUM> and one or more transceivers 1112a, 1112b. A transceiver 1112a, 1112b may be provided for each networking technology supported by the processing circuit. In some instances, multiple networking technologies may share some or all of the circuitry or processing modules found in a transceiver 1112a, 1112b. Each transceiver 1112a, 1112b provides a means for communicating with various other apparatus over a transmission medium. In one example, a transceiver 1112a may be used to couple the apparatus <NUM> to a multi-wire bus. In another example, a transceiver 1112b may be used to connect the apparatus <NUM> to a radio access network. Depending upon the nature of the apparatus <NUM>, a user interface <NUM> (e.g., keypad, display, speaker, microphone, joystick) may also be provided, and may be communicatively coupled to the bus <NUM> directly or through the bus interface <NUM>.

One or more processors <NUM> in the processing circuit <NUM> may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, algorithms, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. The software may reside in computer-readable form in the storage <NUM> or in an external computer-readable medium. The external computer-readable medium and/or storage <NUM> may include a non-transitory computer-readable medium. A non-transitory computer-readable medium includes, by way of example, a magnetic storage device (e.g., hard disk, floppy disk, magnetic strip), an optical disk (e.g., a compact disc (CD) or a digital versatile disc (DVD)), a smart card, a flash memory device (e.g., a "flash drive," a card, a stick, or a key drive), RAM, ROM, a programmable read-only memory (PROM), an erasable PROM (EPROM) including EEPROM, a register, a removable disk, and any other suitable medium for storing software and/or instructions that may be accessed and read by a computer. The computer-readable medium and/or storage <NUM> may also include, by way of example, a carrier wave, a transmission line, and any other suitable medium for transmitting software and/or instructions that may be accessed and read by a computer. The computer-readable medium and/or the storage <NUM> may reside in the processing circuit <NUM>, in the processor <NUM>, external to the processing circuit <NUM>, or be distributed across multiple entities including the processing circuit <NUM>. The computer-readable medium and/or storage <NUM> may be embodied in a computer program product. By way of example, a computer program product may include a computer-readable medium in packaging materials. Those skilled in the art will recognize how best to implement the described functionality presented throughout this disclosure depending on the particular application and the overall design constraints imposed on the overall system.

The storage <NUM> may maintain software maintained and/or organized in loadable code segments, modules, applications, programs, etc., which may be referred to herein as software modules <NUM>. Each of the software modules <NUM> may include instructions and data that, when installed or loaded on the processing circuit <NUM> and executed by the one or more processors <NUM>, contribute to a run-time image <NUM> that controls the operation of the one or more processors <NUM>. When executed, certain instructions may cause the processing circuit <NUM> to perform functions in accordance with certain methods, algorithms and processes described herein.

Some of the software modules <NUM> may be loaded during initialization of the processing circuit <NUM>, and these software modules <NUM> may configure the processing circuit <NUM> to enable performance of the various functions disclosed herein. For example, some software modules <NUM> may configure internal devices and/or logic circuits <NUM> of the processor <NUM>, and may manage access to external devices such as a transceiver 1112a, 1112b, the bus interface <NUM>, the user interface <NUM>, timers, mathematical coprocessors, and so on. The software modules <NUM> may include a control program and/or an operating system that interacts with interrupt handlers and device drivers, and that controls access to various resources provided by the processing circuit <NUM>. The resources may include memory, processing time, access to a transceiver 1112a, 1112b, the user interface <NUM>, and so on.

The one or more processors <NUM> may additionally be adapted to manage background tasks initiated in response to inputs from the user interface <NUM>, the transceiver 1112a, 1112b, and device drivers, for example.

<FIG> is a flowchart <NUM> of a method that is performed by a device coupled to a serial bus. In one example, the serial bus is operated in accordance with SPMI specifications. At block <NUM>, the device receives a write command from the serial bus. The write command is received in a datagram and configured in accordance with an SPMI protocol. At block <NUM>, the device writes a data byte received in a first data frame of the datagram to a register address identified by the datagram.

At block <NUM>, the device uses a second data frame of the datagram to provide feedback regarding the datagram. The device determines at block <NUM> whether the data byte was received without error. In one example, an error may arise during transmission of the data byte transmitted in the first data frame. In another example, the error may be attributed to one or data bytes transmitted in association with the write command. If an error in the data byte was detected or determined at block <NUM>, then at block <NUM> the device drives a data line of the serial bus to provide a negative acknowledgement during the second data frame when a transmission error is detected in the datagram. If no error in the data byte was detected or determined at block <NUM>, then at block <NUM> the device refrains from driving the data line of the serial bus during the second data frame when no transmission error is detected in the datagram, thereby providing an acknowledgement of the datagram. In one example, the second data frame includes nine bit transmission intervals and no data for writing, and may be referred to as a dummy data byte.

The device enables a line driver coupled to a data line of the serial bus to actively drive the data lane to a high signaling state when providing the negative acknowledgement during the second data frame. In one example, the device activates the line driver when a seventh pulse is detected on a clock line of the serial bus during the second data frame, and drives the data line of the serial bus to the high signaling state while an eighth pulse is detected on a clock line of the serial bus during the second data frame. In another example, the device activates the line driver after the data byte is received in the first data frame of the datagram, and drives the data line of the serial bus to the high signaling state while an eighth pulse is detected on a clock line of the serial bus during the second data frame.

The device maintains a line driver coupled to a data line of the serial bus in a high-impedance state during the second data frame when the acknowledgement of the datagram is being provided. The data line is undriven during the eighth and ninth bit transmission intervals of the second data frame. In one example, the data line is pulled to a low signaling state when the data line is undriven.

In one example, the device may use the second data frame of the datagram to provide feedback when a bit of a configuration byte received from the serial bus is set to a first value and ignore the second data frame of the datagram when the bit of the configuration byte received from the serial bus is set to a second value.

In certain examples, the device may provide a bus park sequence on the serial bus after driving the data line of the serial bus during the second data frame. The device may provide the bus park sequence by causing a line driver coupled to a data line of the serial bus to enter a high impedance state at the end of the second data frame.

<FIG> is a diagram illustrating a simplified example of a hardware implementation for an apparatus <NUM> employing a processing circuit <NUM>. The processing circuit typically has a controller or processor <NUM> that may include one or more microprocessors, microcontrollers, digital signal processors, sequencers and/or state machines. The processing circuit <NUM> may be implemented with a bus architecture, represented generally by the bus <NUM>. The bus <NUM> may include any number of interconnecting buses and bridges depending on the specific application of the processing circuit <NUM> and the overall design constraints. The bus <NUM> links together various circuits including one or more processors and/or hardware modules, represented by the controller or processor <NUM>, the modules or circuits <NUM>, <NUM> and <NUM> and the processor-readable storage medium <NUM>. One or more physical layer circuits and/or modules <NUM> may be provided to support communication over a communication link implemented using a multi-wire bus <NUM>, through an antenna or antenna array <NUM> (to a radio access network for example), and so on. The bus <NUM> may also link various other circuits such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art, and therefore, will not be described any further.

The processor <NUM> is responsible for general processing, including the execution of software, code and/or instructions stored on the processor-readable storage medium <NUM>. The processor-readable storage medium <NUM> may include a non-transitory storage medium. The software, when executed by the processor <NUM>, causes the processing circuit <NUM> to perform the various functions described supra for any particular apparatus. The processor-readable storage medium <NUM> may be used for storing data that is manipulated by the processor <NUM> when executing software. The processing circuit <NUM> further includes at least one of the modules <NUM>, <NUM> and <NUM>. The modules <NUM>, <NUM> and <NUM> may be software modules running in the processor <NUM>, resident/stored in the processor-readable storage medium <NUM>, one or more hardware modules coupled to the processor <NUM>, or some combination thereof. The modules <NUM>, <NUM> and <NUM> may include microcontroller instructions, state machine configuration parameters, or some combination thereof.

In one configuration, the apparatus <NUM> includes modules and/or circuits <NUM> adapted to detect or determine errors in received data, including a parity bit condition that may indicate that a transmission error occurred. The apparatus <NUM> may include modules and/or circuits <NUM> adapted to process dummy data bytes, and modules and/or circuits <NUM> adapted to configure, conduct and/or participate in transactions over the multi-wire bus <NUM> configured to operate according to SPMI specifications or protocols. The dummy data bytes may have been transmitted for feedback purposes.

In certain implementations, the apparatus <NUM> includes physical layer circuits and/or modules <NUM> that implement an interface circuit adapted to couple the apparatus <NUM> to the multi-wire bus <NUM>. The apparatus <NUM> may have a processor <NUM> configured to receive a write command from the serial bus where the write command is received in a datagram and configured in accordance with an SPMI protocol, write a data byte received in a first data frame of the datagram to a register address identified by the datagram, and use a second data frame of the datagram to provide feedback regarding the datagram. The processor <NUM> may be configured to drive a data line of the serial bus to provide a negative acknowledgement during the second data frame when a transmission error is detected in the datagram, and refrain from driving the data line of the serial bus during the second data frame when no transmission error is detected in the datagram, thereby providing an acknowledgement of the datagram. In one example, the second data frame includes nine bit transmission intervals and no data for writing.

The apparatus <NUM> may include a line driver coupled to a data line of the serial bus. In some implementations, the processor <NUM> is configured to enable the line driver to actively drive the data lane to a high signaling state when providing the negative acknowledgement during the second data frame. The processor <NUM> may be configured to activate the line driver when a seventh pulse is detected on a clock line of the serial bus during the second data frame, and drive the data line of the serial bus to the high signaling state while an eighth pulse is detected on a clock line of the serial bus during the second data frame. In some implementations, the processor <NUM> is configured to maintain the line driver in a high-impedance state during the second data frame when the acknowledgement of the datagram is being provided. The data line may be undriven during the eighth and ninth bit transmission intervals of the second data frame. The data line may be pulled to a low signaling state when the data line is undriven.

In some implementations, the processor <NUM> is configured to use the second data frame of the datagram to provide feedback when a bit of a configuration byte received from the serial bus is set to a first value, and ignore the second data frame of the datagram when the bit of the configuration byte received from the serial bus is set to a second value.

In some implementations, the processor <NUM> is configured to provide a bus park sequence on the serial bus after driving the data line of the serial bus during the second data frame. In some implementations, the processor <NUM> is configured to cause the line driver coupled to a data line of the serial bus to enter a high impedance state at the end of the second data frame.

The processor-readable storage medium <NUM> may include transitory or non-transitory storage devices configured to store code, instructions and/or parameters used to implement one or more methods or procedures disclosed herein. The processor-readable storage medium <NUM> may include code for receiving a write command from the serial bus. The write command may be received in a datagram and configured in accordance with an SPMI protocol. The processor-readable storage medium <NUM> may include code for writing a data byte received in a first data frame of the datagram to a register address identified by the datagram. The processor-readable storage medium <NUM> may include code for using a second data frame of the datagram to provide feedback regarding the datagram by driving a data line of the serial bus to provide a negative acknowledgement during the second data frame when a transmission error is detected in the datagram and refraining from driving the data line of the serial bus during the second data frame when no transmission error is detected in the datagram, thereby providing an acknowledgement of the datagram.

In one example, the second data frame includes nine bit transmission intervals and no data for writing.

In certain examples, a line driver coupled to a data line of the serial bus may be enabled to actively drive the data lane to a high signaling state when providing the negative acknowledgement during the second data frame. The line driver may be activated when a seventh pulse is detected on a clock line of the serial bus during the second data frame, and the data line of the serial bus may be driven to the high signaling state while an eighth pulse is detected on a clock line of the serial bus during the second data frame.

In certain examples, the processor-readable storage medium <NUM> may include code for maintaining a line driver coupled to a data line of the serial bus in a high-impedance state during the second data frame when the acknowledgement of the datagram is being provided. The data line may be undriven during the eighth and ninth bit transmission intervals of the second data frame. In one example, the data line is pulled to a low signaling state when the data line is undriven.

In one example, the processor-readable storage medium <NUM> may include code for using the second data frame of the datagram to provide feedback when a bit of a configuration byte received from the serial bus is set to a first value and ignoring the second data frame of the datagram when the bit of the configuration byte received from the serial bus is set to a second value.

In certain examples, the processor-readable storage medium <NUM> may include code for providing a bus park sequence on the serial bus after driving the data line of the serial bus during the second data frame. The processor-readable storage medium <NUM> may include code for providing the bus park sequence by causing a line driver coupled to a data line of the serial bus to enter a high impedance state at the end of the second data frame.

<FIG> is a flowchart <NUM> of a method that may be performed by a device coupled to a serial bus. In one example, the serial bus may be operated in accordance with SPMI specifications. At block <NUM>, the device may transmit a write command over the serial bus in a datagram that is configured in accordance with an SPMI protocol. At block <NUM>, the device may transmit a data byte in a first data frame of the datagram. At block <NUM>, the device may provide a bus park sequence on the serial bus in a second data frame of the datagram. At block <NUM>, the device may receive feedback regarding the datagram during the second data frame and after providing the bus park sequence. The feedback may include a feedback bit of the second data frame that indicates a negative acknowledgement when received as a first value, and may indicate an acknowledgement of the datagram when received as a second value.

In one example, the device may provide a bus park sequence by causing a line driver coupled to a data line of the serial bus to enter a high impedance state during a first bit transmission interval in the second data frame. In another example, the device may provide a bus park sequence by causing a line driver coupled to a data line of the serial bus to enter a high impedance state during a seventh bit transmission interval in the second data frame. The data line may be pulled to a signaling state that causes the feedback bit of the second data frame to be received as the second value when the data line is undriven during an eighth bit transmission interval in the second data frame.

In some examples, the write command is addressed to a plurality of devices coupled to the serial bus. The device may configure one or more devices, prior to transmitting the write command, to provide feedback in the second data frame. At least one other device may be configured to ignore the second data frame. For example, the device may configure bit settings of a register located at a zero address in the one or more devices.

In one configuration, the apparatus <NUM> includes modules and/or circuits <NUM> adapted to configure devices coupled to the serial bus to report feedback on errors in received data, including a parity bit condition that may indicate that a transmission error occurred. The apparatus <NUM> may include modules and/or circuits <NUM> adapted to transmit dummy data bytes, and modules and/or circuits <NUM> adapted to configure, conduct and/or participate in transactions over the multi-wire bus <NUM> configured to operate according to SPMI specifications or protocols. The dummy data bytes may be transmitted for feedback purposes.

In certain implementations, the apparatus <NUM> includes physical layer circuits and/or modules <NUM> that implement an interface circuit adapted to couple the apparatus <NUM> to the multi-wire bus <NUM>. The apparatus <NUM> may have a processor <NUM> configured to transmit a write command over the serial bus in a datagram that is configured in accordance with an SPMI protocol, transmit a data byte in a first data frame of the datagram, provide a bus park sequence on the serial bus in a second data frame of the datagram, and receive feedback regarding the datagram during the second data frame and after providing the bus park sequence. The feedback may include a feedback bit of the second data frame that indicates a negative acknowledgement when received as a first value, and may indicate an acknowledgement of the datagram when received as a second value.

In some implementations, the processor <NUM> is configured to cause a line driver coupled to a data line of the serial bus to enter a high impedance state during a seventh bit transmission interval in the second data frame when providing a bus park sequence. The data line may be pulled to a signaling state that causes the feedback bit of the second data frame to be received as the second value when the data line is undriven during an eighth bit transmission interval in the second data frame.

In some instances, the write command is addressed to a plurality of devices coupled to the serial bus. In some implementations, the processor <NUM> configures one or more devices to provide feedback in the second data frame prior to transmitting the write command. At least one other device may be configured to ignore the second data frame.

The processor-readable storage medium <NUM> may include transitory or non-transitory storage devices configured to store code, instructions and/or parameters used to implement one or more methods or procedures disclosed herein. The processor-readable storage medium <NUM> may include code for transmitting a write command over the serial bus in a datagram that is configured in accordance with an SPMI protocol, transmitting a data byte in a first data frame of the datagram, providing a bus park sequence on the serial bus in a second data frame of the datagram, and receiving feedback regarding the datagram during the second data frame and after providing the bus park sequence. The feedback includes a feedback bit of the second data frame that indicates a negative acknowledgement when received as a first value, and indicates an acknowledgement of the datagram when received as a second value.

The processor-readable storage medium <NUM> includes code for causing a line driver coupled to a data line of the serial bus to enter a high impedance state during a seventh bit transmission interval in the second data frame, when providing the bus park sequence. The data line is pulled to a signaling state that causes the feedback bit of the second data frame to be received as the second value when the data line is undriven during an eighth bit transmission interval in the second data frame.

Claim 1:
A method (<NUM>) of data communication at a device coupled to a serial bus, comprising:
receiving (<NUM>) a write command from the serial bus, the write command being received in a datagram and configured in accordance with a System Power Management Interface, SPMI, protocol;
writing (<NUM>) a data byte received in a first data frame of the datagram to a register address identified by the datagram; and
using (<NUM>) a second data frame of the datagram to provide feedback regarding the datagram, including:
driving (<NUM>) a data line of the serial bus to provide a negative acknowledgement during the second data frame when a transmission error is detected in the datagram; and
refraining (<NUM>) from driving the data line of the serial bus during the second data frame when no transmission error is detected in the datagram, thereby providing an acknowledgement of the datagram, further comprising:
enabling a line driver coupled to the data line of the serial bus to actively drive the data line to a high signaling state when providing the negative acknowledgement during the second data frame;
characterized in further comprising:
activating the line driver when a seventh pulse is detected on a clock line of the serial bus during the second data frame; and
driving the data line of the serial bus to the high signaling state while an eighth pulse is detected on the clock line of the serial bus during the second data frame.