TWIS — I²C compatible two-wire interface slave with EasyDMA

TWIS shares registers and other resources with other peripherals that have the same ID as TWIS.

Therefore, you must disable all peripherals that have the same ID as the TWI slave before TWIS can be configured and used. Disabling a peripheral that has the same ID as the TWI slave will not reset any of the registers that are shared with TWIS. It is therefore important to configure all relevant registers explicitly to secure that TWIS operates correctly.

The Instantiation table in Peripherals shows which peripherals have the same ID as TWIS.

TWIS implements EasyDMA for accessing RAM without CPU involvement.

For detailed information regarding the use of EasyDMA, see EasyDMA.

The STOPPED event indicates that EasyDMA has finished accessing the buffer in RAM.

Before TWIS can respond to a read command, it must be configured correctly and enabled via the ENABLE register. When enabled, TWIS will be in its IDLE state.

A read command is started when the TWI master generates a start condition on the TWI bus, followed by clocking out the address and the READ/WRITE bit set to 1 (WRITE=0, READ=1). The READ/WRITE bit is followed by an ACK/NACK bit (ACK=0 or NACK=1) response from the TWI slave.

TWIS is able to listen for up to two addresses at the same time. This is configured in the ADDRESS registers and the CONFIG register.

TWIS will only acknowledge (ACK) the read command if the address presented by the master matches one of the addresses the slave is configured to listen for. TWIS will generate a READ event when it acknowledges the read command.

TWIS is only able to detect a read command from the IDLE state.

TWIS will set an internal 'TX prepared' flag when the PREPARETX task is triggered.

When the read command is received, TWIS will enter the TX state if the internal 'TX prepared' flag is set.

If the internal 'TX prepared' flag is not set when the read command is received, TWIS will stretch the master's clock until the PREPARETX task is triggered and the internal 'TX prepared' flag is set.

TWIS will generate the TXSTARTED event and clear the 'TX prepared' flag ('unprepare TX') when it enters the TX state. In this state TWIS will send the data bytes found in the transmit buffer to the master using the master's clock.

TWIS will go back to the IDLE state if the TWI slave receives a restart command when it is in the TX state.

TWIS is stopped when it receives the stop condition from the TWI master. A STOPPED event will be generated when the transaction has stopped. TWIS will clear the 'TX prepared' flag ('unprepare TX') and go back to the IDLE state when it has stopped.

The transmit buffer is located in RAM at the address specified in the TXD.PTR register. TWIS will only be able to send TXD.MAXCNT bytes from the transmit buffer for each transaction. If the TWI master forces the slave to send more than TXD.MAXCNT bytes, the slave will send the byte specified in the ORC register to the master instead. If this happens, an ERROR event will be generated.

The EasyDMA configuration registers RXD.PTR, TXD.PTR, RXD.AMOUNT, and TXD.AMOUNT, are latched when the TXSTARTED event is generated.

TWIS can be forced to stop by triggering the STOP task. A STOPPED event will be generated when TWIS has stopped. TWIS will clear the 'TX prepared' flag and go back to the IDLE state when it has stopped, see also Terminating an ongoing TWI transaction.

Each byte sent from the slave will be followed by an ACK/NACK bit sent from the master. The TWI master will generate a NACK following the last byte that it wants to receive to tell the slave to release the bus so that the TWI master can generate the stop condition. The TXD.AMOUNT register can be queried after a transaction to see how many bytes were sent.

A typical TWIS read command response is illustrated in the following figure, including clock stretching following a SUSPEND task.

Figure 4. TWIS responding to a read command

Before TWIS can respond to a write command, TWIS must be configured correctly and enabled via the ENABLE register. When enabled, TWIS will be in its IDLE state.

A write command is started when the TWI master generates a start condition on the TWI bus, followed by clocking out the address and the READ/WRITE bit set to 0 (WRITE=0, READ=1). The READ/WRITE bit is followed by an ACK/NACK bit (ACK=0 or NACK=1) response from the slave.

TWIS is able to listen for up to two addresses at the same time. This is configured in the ADDRESS registers and the CONFIG register.

TWIS will only acknowledge (ACK) the write command if the address presented by the master matches one of the addresses the slave is configured to listen for. TWIS will generate a WRITE event if it acknowledges the write command.

TWIS is only able to detect a write command from the IDLE state.

TWIS will set an internal 'RX prepared' flag when the PREPARERX task is triggered.

When the write command is received, TWIS will enter the RX state if the internal 'RX prepared' flag is set.

If the internal 'RX prepared' flag is not set when the write command is received, TWIS will stretch the master's clock until the PREPARERX task is triggered and the internal 'RX prepared' flag is set.

TWIS will generate the RXSTARTED event and clear the internal 'RX prepared' flag ('unprepare RX') when it enters the RX state. In this state, TWIS will be able to receive the bytes sent by the TWI master.

TWIS will go back to the IDLE state if TWIS receives a restart command when it is in the RX state.

TWIS is stopped when it receives the stop condition from the TWI master. A STOPPED event will be generated when the transaction has stopped. TWIS will clear the internal 'RX prepared' flag ('unprepare RX') and go back to the IDLE state when it has stopped.

The receive buffer is located in RAM at the address specified in the RXD.PTR register. TWIS will only be able to receive as many bytes as specified in the RXD.MAXCNT register. If the TWI master tries to send more bytes to the slave than it can receive, the extra bytes are discarded and NACKed by the slave. If this happens, an ERROR event will be generated.

The EasyDMA configuration registers, see RXD.PTR etc., are latched when the RXSTARTED event is generated.

TWIS can be forced to stop by triggering the STOP task. A STOPPED event will be generated when TWIS has stopped. TWIS will clear the internal 'RX prepared' flag and go back to the IDLE state when it has stopped, see also Terminating an ongoing TWI transaction.

TWIS will generate an ACK after every byte received from the master. The RXD.AMOUNT register can be queried after a transaction to see how many bytes were received.

A typical TWIS write command response is illustrated in the following figure, including clock stretching following a SUSPEND task.

Figure 5. TWIS responding to a write command

An example of a repeated start sequence is one in which the TWI master writes two bytes to TWIS followed by reading four bytes from the slave.

This is illustrated in the following figure.

In this example, the receiver does not know what the master wants to read in advance. This information is in the first two received bytes of the write in the repeated start sequence. To guarantee that the CPU is able to process the received data before TWIS starts to reply to the read command, the SUSPEND task is triggered via a shortcut from the READ event generated when the read command is received. When the CPU has processed the incoming data and prepared the correct data response, the CPU will resume the transaction by triggering the RESUME task.

Figure 6. Repeated start sequence

In some situations, e.g. if the external TWI master is not responding correctly, it may be required to terminate an ongoing transaction.

This can be achieved by triggering the STOP task. In this situation, a STOPPED event will be generated when the TWI has stopped independent of whether or not a STOP condition has been generated on the TWI bus. The TWI slave will release the bus when it has stopped and go back to its IDLE state.

To ensure lowest possible power consumption when the peripheral is not needed stop and disable TWIS.

The STOP task may not be always needed (the peripheral might already be stopped), but if the task is triggered, software shall wait until the STOPPED event is generated before disabling the peripheral through the ENABLE register.

The SCL and SDA signals are mapped to physical pins using the PSEL.SCL and PSEL.SDA registers.

The PSEL.SCL and PSEL.SDA registers and their configurations are only used as long as TWIS is enabled, and retained only as long as the device is in System ON mode. When the peripheral is disabled, the pins will behave as regular GPIOs, and use the configuration in their respective OUT bit field and PIN_CNF[n] register. PSEL.SCL and PSEL.SDA must only be configured when TWIS is disabled.

To secure correct signal levels on the pins used by TWIS while in System OFF mode, and when TWIS is disabled, these pins must be configured in the GPIO peripheral as described in the following table.

Only one peripheral can be assigned to drive a particular GPIO pin at a time. Failing to do so may result in unpredictable behavior.