The Teensy 4 is an i.MX RT1062 processor. This document describes the
i.MX RT1062's implementation of the I2C Specification. Its behaviour
is controlled by various registers.
This document defines the relationship between the timing parameters
in the I2C Specification and the i.MX RT1062 registers. It:
- lists the
i.MX RT1062registers that affect the parameter - gives equations to calculate the parameter from the registers
- shows the difference between times measured with
BusRecorderand the I2C Specification
Other documents cover the i.MX RT1062 pin configuration
and the actual values for the I2C parameters
used in this driver.
- I2C Timing on the i.MX RT1062 (Teensy 4)
- Table of Contents
- References
- Symbols and Units
- Measuring and Comparing Durations
- i.MX RT 1060 Registers
- I2C Timing Parameters and Calculations
Information on the i.MX RT1062 is taken from the datasheet;
i.MX RT1060 Processor Reference Manual, Rev. 3 - 07/2021.
References to this datasheet are given like this 47.5.1.24 Slave Configuration 2 (SCFGR2).
Relevant sections:
Chapter 47 - Low Power Inter-Integrated Circuit (LPI2C)
Details of the I2C Specification are taken from the spec itself.
I2C-bus specification and user manual Rev. 6 - 4 April 2014
References to the spec are given like this
I2C Spec. 3.1 Standard-mode, Fast-mode and Fast-mode Plus I2C-bus protocols.
There is a more recent version of the spec. The only significant difference is that v7 replaces the terms "master" and "slave" for "controller" and "target". I've decided to keep using the old terms as they're so widely used.
All durations are given in nanoseconds (ns). Be warned that the I2C Specification uses a mix of microseconds (μs) and nanoseconds.
All symbols are taken from the I2C Specification except for those defined in this section.
- SCL_RISETIME
- the time for SCL line to rise from 0 to the CPU's detection voltage
- the units are LPI2C clock cycles
- see When the i.MX RT1062 Detects Edges for a definition of the detection voltage (it's approx 0.5 Vdd)
- SDA_RISETIME
- the time for SDA line to rise from 0 to the CPU's detection voltage
- the units are LPI2C clock cycles
- see When the i.MX RT1062 Detects Edges for a definition of the detection voltage (it's approx 0.5 Vdd)
The following symbols are not defined in either the I2C Specification or the datasheet.
- trH - time for signal to rise from 0 to 0.7 Vdd
- for an RC curve this = 1.421 tr
- trL - time for signal to rise from 0 to 0.3 Vdd
- for an RC curve this = 0.421 tr
- tfH - time for signal to fall from Vdd to 0.7 Vdd
- for an RC curve this = 0.421 tf
- tfL - time for signal to fall from Vdd to 0.3 Vdd
- for an RC curve this = 1.421 tf
- tLPI2C - period of the LPI2C functional clock on the
i.MX RT1062 - tSCL - period of the SCL clock. Equal to the inverse of the clock frequency = 1/fSCL
- SCALE - scaling factor applied to I2C register values
Where it's necessary to specify the rise or fall time for a specific line then the line is given in a suffix. So trH;SCL is the time for SCL to rise from GND to Vdd.
The I2C Specification allows devices to detect edges anywhere between 0.3 Vdd and 0.7 Vdd. They must see the voltage as LOW below 0.3 Vdd and HIGH above 0.7 Vdd.
This means different devices perceive the intervals between events differently. Each device experiences a slightly different interval to one given in the I2C Specification.
This diagram shows the I2C Specification definition of tSU;DAT and how it may appear to the Teensy, the BusRecorder and a couple of hypothetical devices.
When the I2C Specification specifies the time between 2 edges, it defines the voltages at which the duration begins and ends. For example, tHD;STA begins when SDA falls to 0.3 Vdd and ends when SCL falls to 0.7 Vdd. You need to take account of this if you measure an interval with an oscilloscope.
Section 47.3.1.4 Timing Parameters of the datasheet contains equations
that derive I2C Specification timing values from the register values
used to configure the i.MX RT1062. e.g. tHD;STA
These calculations are somewhat misleading. They appear to give the durations that are defined in the I2C Specification, but they don't. The difference is that the start and end of the durations are the points at which the CPU changes a pin value. For example, for tSU;STO, the start is the moment that SCL is released and starts to rise. The end is the point at which SDA is released and starts to rise.
Similarly, the rise times used in the calculations are not equal to the I2C Specification definitions. Instead, they are the time at which the CPU detects an edge.
I'll describe the datasheet times as the "Datasheet Nominal" times. They are shown on graphs as "Nominal: Datasheet".
The sections below contain the equations needed to map from nominal times to I2C Specification times.
The datasheet takes a pragmatic approach that can be implemented and is not affected by weird rise curves. The conversion equations assume that the rise and fall times follow perfect RC curves.
The BusRecorder is a tool from the i2c-underneath project. It records the time between successive edges, but they're not quite the same intervals as the I2C Specification.
This is because the BusRecorder fires when the voltage passes through 0.5 Vdd.
If you configure its pins to use hysteresis then it actually fires a little
to either side of 0.5 Vdd.
This difference is very significant if the rise times are large or very different for SDA and SCL.
| Pin Mode | Hysteresis | Edge | Detected At | Value for Teensy |
|---|---|---|---|---|
| INPUT | No | Rising | 0.5 Vdd | 1.650 V |
| INPUT | No | Falling | 0.5 Vdd | 1.650 V |
| INPUT_DISABLE | Yes | Rising | 0.5 Vdd + 0.125 V | 1.775 V |
| INPUT_DISABLE | Yes | Falling | 0.5 Vdd - 0.125 V | 1.525 V |
The I2CTimingAnalyser
class analyses traces recorded by the BusRecorder. The results include the various
timings defined in the I2C Specification.
The I2CTimingAnalyser compensates for the fact that the BusRecorder captures
edges around 0.5 Vdd. This relies on the assumption that the rise and
fall curves are perfect RC curves. The compensation will be unrealistic if
the bus does not behave like a perfect Resistor/Capacitor.
The teensy4_i2c driver enables hysteresis on the I2C pins. Its trigger voltages
are the same as the BusRecorder with hysteresis. i.e. 0.538 Vdd for
a rising edge and 0.462 Vdd for a falling edge.
As mentioned above, devices are entitle to detect edges anywhere between 0.3 Vdd and 0.7 Vdd. This means that different devices see these intervals differently.
The I2C Specification is written to account for this. For example, tHD;DAT has a minimum duration but no maximum. It's defined so that different devices will see only slightly longer durations than expected.
The only exceptions to this rule are tVD;DAT and tVD;ACK. These are defined as maximum durations starting with a falling edge on SCL. A device can see a slightly longer duration than expected by reading the falling edge early. As of Nov 2022, I'm not sure if this is significant or not.
- CCM_CSCDR2
14.7.13 CCM Serial Clock Divider Register 2 (CCM_CSCDR2)- LPI2C_CLK_SEL
- selects the base clock speed
- 0 for pll3_sw_clk at 60 MHz clock
- 1 for osc_clk at 24 MHz
- LPI2C_CLK_PODF
- LPI2C clock divider
- LPI2C_CLK_SEL
- MCFGR1
47.5.1.9 Master Configuration 1 (MCFGR1)- PRESCALE
- multiplier applied to all other master settings except FILTSDA and FILTSCL
- PRESCALE
- MCCR0
47.5.1.13 Master Clock Configuration 0 (MCCR0)- CLKLO
- affects tlow low period of the SCL clock pulse
- CLKHI
- affects thigh high period of the SCL clock pulse
- DATAVD
- affects tHD;DAT data hold time
- SETHOLD
- affects tHD;STA hold time for START condition
- affects tSU;STA setup time for repeated START condition
- affects tSU;STO setup time for STOP condition
- CLKLO
- MCFGR2
47.5.1.10 Master Configuration 2 (MCFGR2)- FILTSDA
- affects tSP spike suppression on SDA line
- not affected by PRESCALE
- FILTSCL
- affects tSP spike suppression on SCL line
- not affected by PRESCALE
- BUSIDLE
- affects tBUF minimum bus free time between a STOP and START condition
- FILTSDA
- MCFGR3
47.5.1.11 Master Configuration 3 (MCFGR3)- PINLOW
- configures pin low timeout
- used to detect a stuck bus
- PINLOW
TODO: Not finished
These variables are defined in the datasheet. The datasheet uses them as intermediate variables in the I2C timing equations.
See Table 47-6 in 47.3.2.4 Timing Parameters for the master calculations.
SCALE = (2 ^ PRESCALE) x tLPI2C
Given trt(SDA) = time for SDA to rise to the trigger voltage then the rise time in LPI2C clock cycles is
SDA_RISETIME = tr;SDA / tLPI2C
Given trt(SCL) = time for SCL to rise to the trigger voltage then the rise time in LPI2C clock cycles is
SCL_RISETIME = tr;SCL / tLPI2C
SDA_LATENCY = ROUNDDOWN ( (2 + FILTSDA + SDA_RISETIME) / (2 ^ PRESCALE) )
SCL_LATENCY = ROUNDDOWN ( (2 + FILTSCL + SCL_RISETIME) / (2 ^ PRESCALE) )
The frequency is the inverse of the period tLPI2C. I'll describe everything in terms of the period as that's what we control and measure.
nominal = (CLKHI + CLKLO + 2 + SCL_LATENCY) x scale
fSCL = 1 / nominal
- controlled entirely by the master device
- NOT the same as adding the clock HIGH and clock LOW periods
- starts when SCL falls to 0.3 Vdd
- ends when SCL falls to 0.3 Vdd for a second time
- specifies a maximum frequency (i.e. a minimum period)
Behaviour:
- the processor pulses SCL regularly
- the
i.MX RT1062does not compensate for the SCL rise time - the worst case scenario is that the SCL rise time is very fast
nominal = (CLKLO + 1) x scale
tLOW = nominal - tfL;SCL + trL;SCL
- controlled entirely by the master device
- confirmed that it's not affected by:
- FILTSCL
- FILTSDA
- CLKHI
- DATAVD
- SETHOLD
- IOMUXC_PAD_HYS
- starts when SCL falls to 0.3 Vdd
- ends when SCL rises to 0.3 Vdd
- defines a minimum value but not a maximum
- this allows the bus to be slower than the nominal speed. e.g. running a Standard-mode bus at 50 kHz.
Behaviour:
- the processor
- pulls SCL low
- waits for a fixed time
- then releases SCL again
- there's no compensation for rise or fall times
The worst case scenario is that SCL has a slow fall time and a very fast
rise time. The fall time is controlled entirely by the i.MX RT1062and is
very short so this isn't significant.
nominal = (CLKHI + 1 + SCL_LATENCY) * scale
tHIGH = nominal - trH;SCL + tfH;SCL
- controlled entirely by the master device
- fall time can be neglected
- there's a minimum value but no maximum value
- confirmed that thigh is also affected by:
- IOMUXC_PAD_HYS
- confirmed that thigh is not affected by:
- FILTSDA
- CLKLO
- DATAVD
- SETHOLD
- BUSIDLE
- starts when SCL rises to 0.3 Vdd
- ends when SCL falls to 0.7 Vdd
- defines a minimum value but not a maximum
- this allows the bus to be slower than the nominal speed. e.g. running a Standard-mode bus at 50 kHz.
Behaviour:
- the processor
- release SCL
- waits for SCL to rise to the trigger voltage (just over 0.5 Vdd)
- waits for fixed time
- pulls SCL LOW again
- there's no compensation for the SCL fall time but this is short and can be neglected
The worst case scenario is that SCL has a slow rise time and a very fast
fall time. The fall time is controlled entirely by the i.MX RT1062and is
very short so this isn't significant.
nominal = (SETHOLD + 1 + SCL_LATENCY) x scale
tSU;STA = nominal - trH;SCL + tfH;SDA
- controlled entirely by the master device
- fall time can be neglected
- there's a minimum value but no maximum value
- occurs during a repeated START
- a repeated START allows the master to send another message without sending a STOP
- this reduces latency as there's no need for the STOP or "bus free time" periods
- starts when SCL rises to 0.7 Vdd
- ends when SDA falls to 0.7 Vdd
Behaviour:
- the processor releases the SCL pin allowing SCL to rise
- when it detects that SCL has risen it waits for a time derived from SETHOLD
- this provides limited compensation for different rise times
- when the time has passed it pulls SDA low
Definition:
- starts when the master releases SCL and it starts to rise
- i.e. master sets SCL pin to 1
- ends when the master pulls SDA LOW and it starts to fall
- i.e. master sets SDA pin to 0
Sensitivity to SCL rise time:
- for a fixed SETHOLD
- the setup time falls as the rise time increases
- the setup time increases as FILTSCL increases
- the
i.MX RT1062does not compensate for the whole SCL rise time - so the worst case scenario is that the SCL rise time is very long and the SDA fall time is very short
- the fall time is controlled by the
i.MX RT1062and is very short. This means the fall time has a negligible effect and can be ignored.
nominal = (SETHOLD + 1) x scale
tHD;STA = nominal - tfL;SDA + tfH;SCL
- Controlled entirely by the master device.
- Fall time can be neglected.
- occurs during a START
- starts when SDA falls to 0.3 Vdd
- ends when SCL falls to 0.7 Vdd
In theory, the fall time, tf, might affect the calculation. In practice, it doesn't matter because this calculation is only relevant when the Teensy is acting as a master. In that mode, the fall times are set by the Teensy. They're very fast so they can't have any significant effect.
- according to the datasheet, the
i.MX RT1062does not compensate for the fall times of SDA or SCL - for a particular set of register settings the worst case scenario is that the SDA fall time is very long and the SCL fall time is very short
- both of these edges are controlled by the
i.MX RT1062itself and they're both very short (< 8 ns) and nearly identical - it's therefore safe to ignore the worst case scenario when configuring the device
nominal = (SETHOLD + 1 + SCL_LATENCY) x scale
tSU;STO = nominal - trH;SCL + trL;SDA
- controlled entirely by the master device
Confirmed it depends on:
- PRESCALE
- SCL rise time
- FILTSCL
Confirmed it does not depend on:
- FILTSDA
- occurs before a STOP
- starts when SCL rises to 0.7 Vdd
- ends when SDA rises 0.7 Vdd
- there's a minimum value but no maximum value
Behaviour:
- the processor releases the SCL pin allowing SCL to rise
- when it detects that SCL has risen it waits for a time derived from SETHOLD
- this provides limited compensation for different rise times
- when the time has passed it releases SDA allowing SDA to rise
Definition:
- starts when the master releases SCL and it starts to rise
- i.e. master sets SCL pin to 1
- ends when the master releases SDA and it starts to rise
- i.e. master sets SDA pin to 1
Sensitivity to SCL rise time:
- for a fixed SETHOLD
- the setup time falls as the rise time increases
- the setup time increases as FILTSCL increases
- the
i.MX RT1062does not compensate for the whole SCL rise time - so the worst case scenario is that the SCL rise time is very long and the SDA rise time is very short
WARNING: The actual behaviour of the i.MX RT1062 is significantly different
to the equations given in 47.3.1.4 Timing Parameters.
time_to_rise_to_0_7_vdd = 1.421
time_to_fall_to_0_7_vdd = 0.421
if SDA_RISETIME > 1000:
offset = 1 + ((SDA_RISETIME - 1000) * time_to_rise_to_0_7_vdd) / SCALE
else:
offset = 2
if BUSIDLE > 1
offset = BUSIDLE + 1
nominal = 1000 + SCALE * (CLKLO + 1 + offset)
tBUF = nominal - (SDA_RISETIME * time_to_rise_to_0_7_vdd) + (tf * time_to_fall_to_0_7_vdd)
- controlled entirely by the master device
- tBUF does NOT behave as described in the datasheet
- does NOT depend on FILTSDA
- does not appear to depend on SDA_LATENCY at all
- behaviour is qualitatively different when SDA_RISETIME > 1000 nanoseconds
- the equations above were deduced by fitting measured results
- BUSIDLE does NOT behave as described in the datasheet
- the minimum value given in
47.3.1.4 Timing Parametersdoesn't seem to matter - BUSIDLE is ignored when set to 0
- BUSIDLE does not affect tBUF when SDA_RISETIME > 1000 nanoseconds
- BUSIDLE increases tBUF when SDA_RISETIME < 1000 nanoseconds
- Setting BUSIDLE to 0 does not prevent the driver from deciding that the bus is idle if another master aborts a transaction without a STOP condition
- the minimum value given in
- occurs between a STOP and a START
- SCL is released during the STOP condition
- starts when SDA rises to 0.7 Vdd
- ends when SDA falls to 0.7 Vdd
- there's a minimum value but no maximum value
Behaviour:
- the processor releases the SDA pin allowing SDA to rise (STOP condition)
- waits for a period of time which is a function CLKLO and BUSIDLE
- pulls SDA LOW again (START condition)
Definition:
- starts when the master releases SDA, and it starts to rise
- i.e. master sets SCL pin to 1
- ends when the master pulls SDA LOW, and it starts to fall
- i.e. master sets SDA pin to 0
- the
i.MX RT1062does not compensate for the whole SDA rise time - so the worst case scenario is that the SDA rise time is very long and the SDA fall time is very short
- the fall time is controlled by the
i.MX RT1062and is very short. This means the fall time has a negligible effect and can be ignored.
tLOW = tVD;DAT + tSU;DAT
- controlled by the master if it's transmitting
- could be controlled by the master when the slave is transmitting but the master cannot guarantee this time as the slave could change SDA after the master starts to change SCL
- defined as the minimum time allowed between SDA changing value and SCL starting to rise
- starts when SDA reaches a new value
- if SDA rises then time starts at 0.7 Vdd
- if SDA falls then time starts at 0.3 Vdd
- ends when SDA rises to 0.3 Vdd
- the spec doesn't say whether this applies to ACKs or the setup to a STOP bit. I assume it does as SDA needs to be stable in these cases as well.
- read description of tHD;DAT first
- tSU;DAT is not controlled directly by the driver
- when the master is transmitting then it's a side effect of tVD;DAT
- when a slave transmits then it's determined by when the slave changes SDA. The master probably toggles SCL on schedule regardless.
- if SDA is rising, then the worst case occurs when the SDA rise time is very large
- if SDA is falling, then the worst case is when the SDA fall time is very large
- SDA might be controlled by a slave device with a long fall time
- if the Teensy is the master then the worst case is identical to the I2C value as the Teensy controls the fall time
- in either case, the worst case happens when the SCL rise time is fast
The data hold time applies whether SDA changes from HIGH to LOW or vice versa. The first of these graphs shows SDA rising and the second shows SDA falling.
We know that SCL will fall very fast for a Teensy in master mode as it controls SCL. A Teensy slave might see a very slow falling edge. These 2 graphs highlight this difference.
nominal = (DATAVD + 1) x scale
tHD;DAT = nominal - tfL;SCL + (trL;SDA or tfH;SDA)
tfL;SCL is negligible on the Teensy and can be ignored in practice
given tft;SCL is time to for SCL to fall from the trigger voltage to 0.3 Vdd
nominal = (FILTSCL + DATAVD + 3) x tLPI2C
tHD;DAT = nominal - tf;SCL + (trL;SDA or tfH;SDA)
- the data hold time is determined by whichever device is changes SDA
- the data hold time ensures that a device never sees SDA change unless SCL is LOW
- note 3 of Table 10 of
I2C Spec. 6.1 Electrical specifications and timing for I/O stages and bus linesrefers to an "internal" hold time. This is necessary to avoid the edge case where SCL has a very slow fall time and SDA changes very fast. If one device decides that SCL fell at 0.65 Vdd and changes SDA, but the other device doesn't decide SCL fell until it reaches 0.35 Vdd, then the second device could see the change on SDA before the change in SCL. This can't happen if the first device waits for the maximum fall time before changing SDA. - in the edge case above, the "external" data hold time is negative
- a slave device can probably get away with a very short or 0 length hold time. The master pulled SCL LOW and so presumably thinks SCL is LOW irrespective of the fall time. It will almost certainly see any change to SDA as happening when SCL is LOW irrespective of how fast the slave reacts.
- time starts when SCL falls to 0.3 Vdd
- time ends when SDA starts to change. i.e. rises to 0.3 Vdd or falls to 0.7 Vdd
- the I2C Specification doesn't make it clear whether the hold time applies after the START bit and before the STOP bit. I assume it does, because the purpose of the data hold time is to make sure that data bits are not confused with STOP or START bits.
There are 2 different conditions. In the first case, the Teensy is the master device, and it controls SDA. In the second, the Teensy is the slave device, and it controls SDA.
Note that the Teensy configures DATAVD separately for master and slave modes.
- starts when the processor pulls SCL LOW and SCL starts to fall
- the processor waits for a period of time which depends on DATAVD
- ends when the processor changes the value of SDA pin and SDA starts to change
- starts when the processor detects that SCL has fallen (approx 0.5 Vdd on the Teensy)
- the processor waits for a period of time which depends on DATAVD
- ends when the processor changes the value of SDA pin and SDA starts to change
The worst case occurs when SCL falls very slowly and SDA changes very fast. Fall times are usually much faster than rise times, so this probably involves SDA falling.
The worst case also happens when SCL falls very slowly and SDA changes very fast. It probably doesn't matter though because the master already thinks SCL is LOW and so can't confuse the order of the edges.
tVD;DAT is identical to tHD;DAT except that includes the time for SDA to finish changing. Please read the section for Data Hold Time first.
The nominal time is identical to the nominal for tHD;DAT. The I2C time is identical to the I2C time for tHD;DAT plus the SDA rise time if SDA is rising, or the fall time if SDA is falling.
nominal = (DATAVD + 1) x scale
tVD;DAT = tHD;DAT + (tf or tr)
given tft;SCL is time to for SCL to fall from the trigger voltage to 0.3 Vdd
nominal = (FILTSCL + DATAVD + 3) x tLPI2C
tVD;DAT = tHD;DAT + (tf or tr)
- the I2C Specification sets a maximum value for data valid time. It doesn't explain why this is required.
- the limitation on tVD;DAT applies only if the clock is not stretched
- tVD;ACK is identical to tVD;DAT except that it applies to ACKs instead of data bits
- tLOW = tVD;DAT + tSU;DAT
tVD;ACK is identical to tVD;DAT except that it applies to an ACK rather than a data bit.
#### Notes
#### I2C Specification
#### Datasheet Nominal