tags: `TSC` `Linux` `I2C`

I2C 學習

介紹

I2C（Inter-Integrated Circuit），中文稱為"兩線式串行總線"，是一種廣泛使用的串行匯流排，主要用於嵌入式系統中的微控制器與外部裝置之間的通訊。I2C由飛利浦半導體（現在的恩智浦半導體）在1980年代初開發，具有以下幾個關鍵特點：

簡單的兩條信號線：I2C通訊只需要兩條線，一條是數據線（SDA）和一條時鐘線（SCL）。
多主多從架構：I2C允許多個主裝置（發送命令的裝置）和多個從裝置（接收命令的裝置）在同一條線上共存。
地址化：每個從裝置都有一個唯一的地址，主裝置可以通過地址來選擇與哪個從裝置通信。
同步通信：所有的數據傳輸都是在時鐘信號的控制下進行，確保數據的正確性和時序的一致性。
支持不同的數據傳輸速率：標準模式下最高100 Kbps，快速模式下最高400 Kbps，還有更快的速度，如快速模式加（1 Mbps）和高速模式（3.4 Mbps）。
I2C技術被應用於多種電子設備中，例如在計算機、手機、電視等消費性電子產品中用於連接小型組件如感測器、微控制器等。由於其設計簡潔且有效，能夠支持多裝置之間的連接，I2C成為了許多電子產品和嵌入式系統的首選通訊協議。

I2C SPEC and i2c-bus.org
https://www.nxp.com/docs/en/application-note/AN10216.pdf
https://www.nxp.com/docs/en/user-guide/UM10204.pdf
Clock Stretching
https://www.i2c-bus.org/clock-stretching/
Fast Mode Plus
https://www.i2c-bus.org/fast-mode-plus/

I2C lock

當使用 I2C（Inter-Integrated Circuit）通訊協議時，有時可能會遇到稱為「I2C 鎖定」的狀態。這通常是指 I2C 總線被意外鎖定或阻塞，導致數據傳輸無法正常進行。這種情況可以由多種原因引起，以下是一些常見的原因：

硬體故障：如果 I2C 總線上的任何裝置發生硬體故障，例如連接線斷裂或接觸不良，可能導致信號無法正確傳輸，進而導致總線鎖定。
韌體/軟體問題：錯誤的韌體或軟體邏輯可能導致某個裝置在沒有釋放總線的情況下持續保持控制權，或者在某個操作未完成時就終止通信，這將導致總線無法使用。
噪音或電氣干擾：在電氣環境嘈雜的情況下，I2C 總線可能受到干擾，導致數據錯誤或通信中斷。
過長的總線線路或過多的裝置：如果 I2C 總線過長或連接的裝置過多，可能會導致信號衰減或反射，增加錯誤率並可能導致總線鎖定。

解決 I2C 鎖定的方法取決於問題的原因，通常包括以下幾種：

硬體檢查與修正：檢查所有的連接是否正確無誤，包括線路、接頭和裝置端點。
軟體重置：在發生鎖定時，可以通過軟體重置涉及的裝置來嘗試釋放總線。
改善總線設計：縮短總線長度，減少連接的裝置數量，使用更適合的拉上電阻，或添加總線隔離裝置。
錯誤處理程式：在韌體或軟體中加入錯誤處理機制，如監測並處理未完成的通信操作。

正確地處理這些問題不僅可以解決當前的鎖定問題，還可以預防未來可能的類似事件。

改善BUS 電路設計

縮短總線長度，減少連接的裝置數量，使用更適合Pull up電阻，或添加總線隔離裝置。

I2C pull up Resistance 計算

公式

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

Rp(max)推導

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

Example

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

ref:

I2C Design Mathematics: Capacitance and Resistance:
https://www.allaboutcircuits.com/technical-articles/the-i2c-bus-hardware-implementation-details/

I2C pull up resistor calculation, bus capacitance, and rise time lecture 9
http://fastbitlab.com/i2c-pull-up-resistance-rise-time-and-bus-capacitance-discussion/

教學影片
https://www.youtube.com/watch?v=sGZe0aJsqBQ
https://www.youtube.com/watch?v=CEPFWAPDy7o

先算完再來量, 應該就會接近, 要注意一點, 電容在IC內部若是用類比的方式做, 不同IC誤差很大, 但如果電容是數位模擬的IC, 通常差異不大

教你精确计算 I2C 上拉电阻阻值
https://cloud.tencent.com/developer/article/1916204

https://rheingoldheavy.com/i2c-pull-resistors/
漏极开路上拉电阻取值为何不能很大或很小?
http://www.3ctest.cn/news/show/535

BUS 電容

NXP 有規範Device IO Pin 的接面電容不可以大於10 pF，我想大部分的device 都會符合這個規範:

Image Not Showing Possible Reasons

The image file may be corrupted
The server hosting the image is unavailable
The image path is incorrect
The image format is not supported

Learn More →

I2C Bus 除了Pull high 電阻需要警慎使用外， “BUS 電容” 我覺得比Pull high 電阻還重要，因為它不好去確認，而且變數更多。但我們只能有效控制” “BUS 電容”不要太大就已足夠。

(Rp max 取決於 Cb)
Image Not Showing Possible Reasons
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Learn More →
由於I2C device 是外接，除了IC 本身的接面電容外還有線材上的電容效應，當BUS 上有很多Device 時，電容會越併越大，我們應該注意不能超出 SPEC 的 400 pF (on Fast mode 400Khz)
以下為 SPEC 提出降低電容效應的方法，我列出一些重點以及個人看法
Image Not Showing Possible Reasons
- The image was uploaded to a note which you don't have access to
- The note which the image was originally uploaded to has been deleted
Learn More →
- Reduced fSCL : 降低操作頻率
- Higher drive outputs: 提升軀動能力
- Bus buffers: 使用一個Buffers 準位準態 or 提升軀動能力
- Switched pull-up circuit: 利用電路切換 Pull High 的使用來降低電容效應. (這我不是很懂)
  Image Not Showing Possible Reasons
  The image was uploaded to a note which you don't have access to
  The note which the image was originally uploaded to has been deleted
  Learn More →
改善 I2C BUS 走線

若大於 10 cm SPEC有建議走線方式，若我們願意使用雙絞線 SPEC建議 SDA 跟SCL 跟Vss 絞在一起或者 SDA跟 Vdd ; SCL 跟Vss。我想這可以多少降低一些串擾(crosstalk)以及兩條線之間的電容效應.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

有個看似專門處理 I2C Bus電容過大的IC: LTC4315

LTC4315 介紹
推測 I2C Bus 上的電容.
Rp(max) 的公式是由 RC 充放電的公式推倒而來，而在實際應用下我們已固定Rp ，理論上可以透過量測 Tr 來推測目前Target board I2C Bus 上的電容.
而理論上 Cb 不應該過大 ( < 400pF on 400khz Fast mode).

Cb = Tr/ ( 0.8473x Rp)
[Rp (max) 公式推導]

[Tr]

[Rp Vs Cb]

而 Rp 在 Fast-mode 下 tr 最大為300 ns, 若預估 Bus 最大電容在 200 pF 以內 (雖然Cb Fast-mode 規範在 400 pF 以下，但實際上超過 200pF 波型應該就不太好)，它適合的最大阻值是 1.77 K ohm.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

ref:

CAN總線電容過大的三種解決方案
https://kknews.cc/zh-tw/news/99l24g5.html

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

如何確認哪一個 device 把 I2C Bus 鎖住

我們可以在 MCU (Master) 端加上一個 Rs 的串阻，然後在 Device (slave) 端也加上一個串阻，這樣當I2C lock 時 SDA 被拉Low 時可以在一個量測點，量到不同電壓，進而可以判斷是哪邊把腳位拉低.
而Rs 預設可以為 0 ohm ，也可以加些阻抗來抑制一些overshot 。當我們在抓問題的時候可以匹配成適合的阻值，來定位哪個Device 有問題。或許某個 device 的 VIL 過高，又或者不符合I2C 的SPEC，這個時候可以思考把那個device 獨立一個 I2C Bus 控制，不與其它I2C裝置並接.

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

PCB layout 抗干擾設計

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

https://community.infineon.com/t5/知识库文章/为什么串行通信线路上需要串联终端电阻-KBA225247/ta-p/258711

https://community.infineon.com/t5/Knowledge-Base-Articles/Need-for-Series-Termination-Resistors-on-Communication-Lines/ta-p/252049

Image Not Showing Possible Reasons

The image was uploaded to a note which you don't have access to
The note which the image was originally uploaded to has been deleted

Learn More →

I2C 軟體重置

How can I2C lock up?

Now to the problem: in some circumstances the I2C bus can “lock up” in a busy state which prevents the master from ever being able to start a new transaction. Since the master controls the transactions on the bus, this means nothing else can happen after the lock-up occurs. Obviously, this could be a show-stopping condition for any system that depends on the I2C bus to scan sensors or read from EEPROM, for example.

That raises several questions including:

what causes I2C lock-up?
how can lock-up be detected and recovered from?
how can lock-up be prevented?

To understand how the I2C bus can lock up, it’s helpful to think of things from the perspective of a slave device. The slave must monitor the state of the clock and data signals, and in particular must look out for transitions of either signal which may indicate the start or end of a transaction or the need to clock data in and out. All will be well provided the slave device sees the same series of transitions that the master generates, assuming they conform to the I2C protocol specification.

But if there’s some noise or interference that causes an unwanted extra transition or masks a wanted transition, the slave can get out of step with the master. For example, if the master needs to transfer one byte of data from the slave, the slave is expecting to see a specific number of transitions on the clock signal to clock each bit of the data out (and to provide an acknowledge signal). If a clock edge gets “lost” somehow, the slave device will never finish transferring the data and may end up continuously pulling the data line to an active low state.

Now the master might “think” that the transaction has finished, so won’t issue any more clocks, but the slave “thinks” the transaction is still in progress so will keep the bus in a busy state. While the bus is busy, the master can’t generate any more clock transitions. While there are no clock transitions from the master, the slave won’t let go of the bus.

Another situation where lock-ups might occur is during start-up when i/o signals from the master might have glitches or other unexpected transitions before they are stable. If an I2C slave device is monitoring the bus before the master brings the clock and data lines into the right (passive) state, this can cause the I2C bus to be locked before the master starts the first transaction.

Finally, even if the bus is very well-behaved and doesn’t suffer from noise or glitches, lock-up can occur during software development. Let’s say you’re testing and debugging a system using I2C and your software crashes or hits a breakpoint while an I2C transaction is in mid-flight. If you simply reset the CPU or re-start the software, the I2C slave will never see the end of that transaction so the I2C bus will be locked when the software re-starts.

How should my design handle lock-up?

So, I2C lock-up is definitely “a thing” in practice as well as theory. What can be done about it?

The first approach is prevention. This largely depends on good electronic design to minimise the chance of noise and glitches. For example, this might include:

using “strong” pull-ups to speed up the rising edge of the SCL and SDA signals
using i/o signals on the I2C master that have default “high” state, possibly with pull-ups, when the master comes out of reset

Software can sometimes also play a role: if the software running on the master has to configure the signals used by the I2C interface, be careful to make sure that the configuration sequence can’t introduce any unwanted transitions.

Despite the best intentions to prevent lock-up, it’s good practice when designing a system based on I2C to assume that lock-up can occur and to make the system resilient by detecting and recovering from it. This is usually a burden placed on the master software, although hardware design can also help out.

The basic principles here are:

always implement a well-defined time-out period when waiting for any I2C event
if a time-out occurs that might indicate a lock-up, either reset all the slave devices or issue a sequence of at least ten clock cycles on the I2C SCL signal

All production-quality I2C device drivers should support time-outs when waiting for I2C events such as gaining access to the bus and completion of data transfers. Depending on the design, the I2C master may include a dedicated controller that might have hardware support for time-outs, in which case the driver should use it. Otherwise, or if the master uses “bit-banged” discrete input/output signals to drive the I2C interface, the I2C driver might have to use software time-outs. Either way, if a time-out occurs it could mean that the I2C bus has locked up and some recovery action needs to be taken. (One exception to this is if you’re dynamically “probing” the I2C bus to discover what devices are on it, but that is not very typical in production software for an embedded system.)

The best recovery action will also depend on the hardware design. In the best case, the hardware will allow each I2C slave device to be reset by the software on the master. For example, this could be done by toggling one or more discrete output signals. Otherwise, the best recovery action is usually to force a series of at least ten clock pulses out on the I2C clock signal. Why ten pulses? Because typically it takes nine clock pulses to clock one data byte in or out of a slave device, after which it will normally release the bus.

If the hardware has a dedicated I2C controller, generating this sequence of pulses might not be straightforward because the controller hardware might not give you direct access to drive the clock signal. In that case, you may have to re-configure the I2C clock pin so that it can be driven as a bit-banged discrete output. In any case, make sure that the clock pulses are generated at about the right frequency (e.g. 100 kHz or 400 kHz), and definitely no faster than the maximum clock rate of any device on the bus.

How about a real-world example?

Here’s a typical piece of code taken from a system I worked on recently to generate this clock sequence. The master was an NXP KL17 micro-controller, which has a built-in I2C controller. The KL17 I2C controller doesn’t let software drive the clock directly, so I had to configure the SCL signal as a bit-banged output for the recovery sequence, then re-configure it to be used by the I2C controller for normal operation:

























































/**
* @brief Definitions
*/
#define I2C_RECOVER_NUM_CLOCKS      10U     /* # clock cycles for recovery  */
#define I2C_RECOVER_CLOCK_FREQ      50000U  /* clock frequency for recovery */

#define I2C_RECOVER_CLOCK_DELAY_US  (1000000U / (2U * I2C_RECOVER_CLOCK_FREQ))

...

/**
* @brief  Recover I2C from potential lock-up condition
*
* Issue a sequence of ten clock cycles on the I2C SCL i/o pin, without regard
* to the normal I2C protocol.  This is intended to recover from a lock-up
* condition whereby a slave is driving SDA low because it is stuck in mid-
* transaction.  This condition should not occur during normal start-up from
* power-up, but it may occur if the software is re-started (e.g. during a
* debugging session).
*/
void i2cLockupRecover (void)
    {
    /*
     * Configure SCL pin as GPIO.
     */
    PORT_SetPinMux (I2C_SCL_PORT, I2C_SCL_GPIO_PIN, kPORT_MuxAsGpio);

    /*
     * Initialise pin direction and initial state (high).
     */
    const gpio_pin_config_t pinConfig =
        {
         .pinDirection = kGPIO_DigitalOutput,
         .outputLogic  = 1U,
        };

    GPIO_PinInit (I2C_SCL_GPIO_PORT, I2C_SCL_GPIO_PIN, &pinConfig);

    /*
     * Synthesise several clock cycles; leave i/o pin high.
     */
    for (unsigned int i = 0U; i < I2C_RECOVER_NUM_CLOCKS; ++i)
        {
        delayUs (I2C_RECOVER_CLOCK_DELAY_US);

        GPIO_PinWrite (I2C_SCL_GPIO_PORT, I2C_SCL_GPIO_PIN, 0U);

        delayUs (I2C_RECOVER_CLOCK_DELAY_US);

        GPIO_PinWrite (I2C_SCL_GPIO_PORT, I2C_SCL_GPIO_PIN, 1U);
        }

    /*
     * Reconfigure i/o pin as I2C SCL.
     */
    PORT_SetPinMux (I2C_SCL_PORT, I2C_SCL_GPIO_PIN, kPORT_MuxAlt4);
    }

Another piece of good practice is to always issue the “lock-up recovery” clock sequence when the master software starts up. Then any potential glitches during power-up won’t cause the bus to lock up before things get properly started. This technique can also make life much less frustrating when you’re re-starting a system without power-cycling it – for example, during a debugging session.

Here’s a trace showing the software-generated recovery sequence produced by the code above when the system starts up, shortly followed by the first “real” I2C transaction:

Logic analsyser trace of I2C lock-up recovery

If you’re planning to use I2C in your embedded system design, or are already using it, I hope this has given some insight into the potential for lock-up and how to avoid it, or detect and recover from it. May all your designs be lock-up free.

ref:

如何在 linux 使用 I2C

世平集團代理的NXP i.MX8M Mini多核心應用處理器包含了豐富周邊介面，我們今天來探討如何在Linux上做i2c的除錯。在恩智浦原生Linux BSP Build code完成後就有內建i2c工具，讓開發者可以簡單的利用指令存取i2c周邊裝置的暫存器以便確認CPU端對裝置端讀取是否正常，以便可以縮短整個開發時程。

以下我們使用NXP i.MX8M Mini的開發板及NXP PCF85063TP RTC實時時鐘為各位說明。