TWIM — I2C compatible two-wire interface master with EasyDMA

TWIM shares registers and other resources with other peripherals that have the same ID as the TWI master. Therefore, you must disable all peripherals that have the same ID as TWIM before it can be configured and used.

Disabling a peripheral that has the same ID as TWIM will not reset any of the registers that are shared with TWIM. It is therefore important to configure all relevant registers explicitly to secure that TWIM operates correctly.

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

TWIM implements EasyDMA for accessing RAM without CPU involvement.

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

The RXD.PTR, TXD.PTR, RXD.MAXCNT, and TXD.MAXCNT registers are double-buffered. They can be updated and prepared for the next RX or TX transmission immediately after having received the RXSTARTED or TXSTARTED event.

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

A TWIM write sequence is started by triggering the STARTTX task. After the STARTTX task has been triggered, TWIM 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 address must match the address of the slave device that the master wants to write to. The READ/WRITE bit is followed by an ACK/NACK bit (ACK=0 or NACK=1) generated by the slave.

After receiving the ACK bit, TWIM clocks out the data bytes found in the transmit buffer located in RAM at the address specified in the TXD.PTR register. Each byte clocked out from TWIM will be followed by an ACK/NACK bit clocked in from the slave.

A typical TWIM write sequence is shown in the following figure, including clock stretching performed by TWIM following a SUSPEND task.

A SUSPENDED event indicates that the SUSPEND task has taken effect. This event can be used to synchronize the software.

TWIM will generate a LASTTX event when it starts to transmit the last byte.

TWIM is stopped by triggering the STOP task. This task should be triggered during the transmission of the last byte to secure that TWIM will stop as fast as possible after sending the last byte. The shortcut between LASTTX and STOP can alternatively be used to accomplish this.

A TWIM read sequence is started by triggering the STARTRX task. After the STARTRX task has been triggered, TWIM 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 address must match the address of the slave device that the master wants to read from. The READ/WRITE bit is followed by an ACK/NACK bit (ACK=0 or NACK = 1) generated by the slave.

After sending the ACK bit, the TWI slave sends data to the master using the clock generated by TWIM.

Data received will be stored in RAM at the address specified in the RXD.PTR register. The TWI master will generate an ACK after all but the last byte have been received from the slave. TWIM generates a NACK after the last byte received to indicate that the read sequence shall stop.

A typical TWIM read sequence is illustrated in the following figure, including clock stretching performed by TWIM following a SUSPEND task.

A SUSPENDED event indicates that the SUSPEND task has taken effect. This event can be used to synchronize the software.

TWIM generates a LASTRX event when it is ready to receive the last byte. If RXD.MAXCNT > 1, the LASTRX event is generated after sending the ACK of the previously received byte. If RXD.MAXCNT = 1, the LASTRX event is generated after receiving the ACK following the address and READ bit.

TWIM is stopped by triggering the STOP task. This task must be triggered before the NACK bit is supposed to be transmitted. The STOP task can be triggered at any time during the reception of the last byte. It is recommended to use the shortcut between LASTRX and STOP to accomplish this.

TWIM does not stop by itself when the RAM buffer is full, or when an error occurs. The STOP task must be issued, through the use of a local or PPI shortcut, or in software as part of the error handler.

TWIM cannot be stopped while suspended, so the STOP task must be issued after TWIM has been resumed.

A typical repeated start sequence is when TWIM writes two bytes to the slave followed by reading four bytes from the slave. This example uses shortcuts to perform the simplest type of repeated start sequence, i.e. one write followed by one read. The same approach can be used to perform a repeated start sequence where the sequence is read followed by write.

The following figure shows an example of a repeated start sequence where TWIM writes two bytes followed by reading four bytes from the slave.

If a more complex repeated start sequence is needed, and the TWI firmware drive is serviced in a low priority interrupt, it may be necessary to use the SUSPEND task and SUSPENDED event to guarantee that the correct tasks are generated at the correct time. A double repeated start sequence using the SUSPEND task to secure safe operation in low priority interrupts is shown in the following figure.

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

When the STOP task is sent, the software shall wait until the STOPPED event is received as a response before disabling the peripheral through the ENABLE register. If the peripheral is already stopped, the STOP task is not required.

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 the TWI master 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 the TWI master is disabled.

To secure correct signal levels on the pins used by TWIM while in System OFF mode, and when TWIM 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.