Elektroda.pl
Elektroda.pl
X
Tektronix
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Debuggowanie I2C z pomocą oscyloskopu

ghost666 07 Sie 2019 14:56 1419 0
  • Jest szereg powodów, dla którego I²C jest jednym z najczęściej używanych protokołów w systemach wbudowanych do komunikacji. Projektanci wolą I²C, ponieważ wymaga tylko dwóch przewodów: linii danych (SDA) i linia zegara (SCL). Linie te umożliwiają wielu urządzeniom
    komunikowanie się poprzez jedynie te dwie linie. Prostota I²C nie oznacza jednak, że implementacja tego interfejsu nie jest wyzwaniem.

    Problemy z komunikacją I²C obejmują zbyt wolne czasy narastania sygnału, przesłuchy (i co gorsze, fałszywe zbocza na linii SCL), wyższe niż zamierzone napięcia VOL (napięcie poziomu niskiego), niezamierzone konflikty na liniach oraz zbyt niską amplitudę sygnału. Te problemy mogą prowadzić do niepoprawnej komunikacji poprzez I²C i doprowadzić do awarii urządzenia. Problemy te z łatwością można diagnozować z pomocą oscyloskopu.

    Zrozumienie wyzwań i właściwe nauczenie się procedury debuggowania - analizy przebiegu I²C, mogą pomóc w precyzyjnym określeniu problemów z komunikacją podczas pracy z tym interfejsem. Poniższy artykuł omawia, jakie działanie i wyzwania związane są z debugowaniem interfejsu I²C oraz na jakie typowe problemy możemy się natknąć.

    Duże czasy narastania

    Czasy narastania zazwyczaj stanowią problem, gdy są zbyt wolne, potencjalnie powodując, że sygnał nigdy nie dociera do progu napięcia stanu wysokiego (VIH) w odpowiednim czasie. Jako że na czasy narastania wpływa wiele elementów interfejsu - rezystory podciągające, pojemność szyn i inne, problemy z czasem narastania można zazwyczaj najprościej rozwiązać za pomocą silniejszego podciągnięcia linii do stanu wysokiego, co oznacza, zastosowanie opornika o niższej rezystancji. Interfejs I²C określa maksymalne dozwolone czasy narastania w oparciu o maksymalną częstotliwość zegara używanego w systemie. W wersji 2.6 specyfikacji I²C maksymalny czas narastania dla standardowego i szybkiego trybu pracy wynosi, odpowiednio, 1000 ns i 300 ns.

    Rysunek 1 pokazuje sygnał zegarowy (SCL), który ma problematyczny czas narastania. SCL nigdy nie osiąga 100% napięcia zasilania. Ten zbyt wolny czas narastania wpływa na czas trwania stanu wysokiego w czasie okresu zegara, ponieważ sygnał potrzebuje więcej czasu, aby osiągnąć 70% VCC (3,5 V w tym przypadku, gdzie VCC wynosi 5 V). Na rysunku 1 czas narastania zbocza (dla trybu standardowego) jest zbyt duży, ponieważ maksymalny dozwolony czas wynosi 1000 ns, a zmierzony w tym przypadku czas równy jest 2500 ns.

    Niektóre urządzenia I²C są uruchamiane poprzez wykrywanie odpowiednio szybkiego zbocza sygnału, co oznacza, że zbyt wolno narastający impuls spowoduje, że układ taki nie wykryje w ogóle zbocza, co doprowadzić może do niepoprawnego działania systemu.

    Debuggowanie I2C z pomocą oscyloskopu
    Rys.1. Linie z dużym obciążeniem pojemnościowym i słabymi opornikami podciągającymi charakteryzują się niedostatecznie szybkim narastaniem zbocz sygnałów.


    Jest jednak druga strona medalu. W rzadkich przypadkach ekstremalnie szybkie czasy narastania/opadania zbocza mogą fałszywie wyzwalać zabezpieczenia przez wyładowaniami elektrostatycznymi (ESD) na pinach SDA lub SCL urządzeń w sieci I²C, które normalnie wyzwalane są częstotliwością graniczną. Powoduje to blokowanie tych linii do momentu odzyskania sprawności przez zabezpieczenie ESD. Sytuacja taka występuje zwykle wtedy, gdy urządzenie podrzędne I²C o częstotliwości pracy równej 400 kHz znajduje się na aktywnej magistrali I²C, która pracuje z częstotliwością 1 MHz lub większą. Fałszywe wyzwolenie zabezpieczenia jest zazwyczaj wynikiem niewłaściwego umieszczenia lub izolacji układów podrzędnych w sieci I²C. W ogólności nie należy umieszczać urządzeń podrzędnych 400 kHz w sieciach I²C działających szybciej niż 400 kHz.

    Przesłuch

    Zwykle widoczny jest na linii danych (SDA), chociaż może występować również na linii zegarowej (SCL), przesłuch jest wynikiem szybkich czasów narastania/opadania na linii i sprzężenia pojemnościowego ze sobą obu linii - SCL i SDA. Sprzężenie to odbywa się poprzez pojemność pasożytniczą dwóch równolegle prowadzonych linii.

    Rysunek 2 pokazuje oscylogramy linii SDA i SCL podczas aktywnej komunikacji na linii I²C, w której widoczny jest przesłuch podczas narastających i opadających krawędzi sygnałów. Na rysunku 2 przesłuch nie wpływa na integralność sygnałów, ponieważ linia danych (SDA) pozostaje powyżej VIH lub poniżej VIL w czasie stanu wysokiego na linii zegarowej (kiedy dane są rzeczywiście próbkowane).

    Debuggowanie I2C z pomocą oscyloskopu

    Rys.2. Przykład niewielkiego przesłuchu, który tylko marginalnie ma wpływ na integralność sygnałów interfejsu I²C.[/center]

    Przesłuch pomiędzy liniami SDA i SCL może być problematyczny, jeśli w magistrali znajdują się bufory/translatory z akceleratorami czasu narastania. Urządzenia z akceleratorami narastania mogą wyzwalać zbocze narastające powyżej progu niskiego poziomu napięcia wejściowego (VIL). W wersji 2.6 specyfikacji I²C VIL jest zdefiniowany na 30% VCC. Tak więc, każdy przesłuch, który powoduje narastanie zbocza ponad wartość VIL, spowoduje włączenie akceleratorów czasu narastania. W niektórych przypadkach na linia SDA nie spowoduje to negatywnych konsekwencji, ale w przypadku linii SCL skończyć może się to generowaniem fałszywego zbocza narastającego dla urządzenia podrzędnego i może w rzeczywistości przerwać działanie maszyny stanu urządzenia podrzędnego, co może spowodować nieprawidłowy odczyt danych lub nawet zablokowanie magistrali.

    Dodanie dodatkowej pojemności na magistrali w liniach SDA oraz SCL może pomóc, ale wartość pojemności, którą można dodać, jest mocno ograniczona ze względu na maksymalną pojemność całej magistrali, wymienioną w specyfikacji I²C - 400 pF zarówno w trybie standardowym, jak i szybkim dla wersji 2.6 I²C specyfikacja. Najlepszym podejściem do rozwiązywania problemu przesłuchów jest umieszczenie małych szeregowych rezystorów w liniach SDA/SCL i zminimalizowanie pasożytniczej pojemności magistrali między ścieżkami SDA i SCL.

    Wyższy poziom VOL niż założony

    Wysoki poziom napięcia progowego stanu niskiego – VOL – może sprawiać problemy, gdyż w sytuacji takiej układy interpretuje niepotrzebnie sygnały jako logiczny stan niski. Niektóre urządzenia slave I²C (zwłaszcza starsze) mają na wejściu słabej klasy tranzystory polowe (FET) i generują wysoki poziom VOL, który może nie spełniać standardu VIL (szczególnie w przypadku niskiego VCC, takiego jak logika 1,8 V lub 1 V). Innym powodem tego może być wybór rezystorów podciągających – zbyt silne podciągnięcie (tj. oporniki o za małej wartości), może skutkować poziomami VOL wyższymi niż VIL, ustawiając w ten sposób linię w stanie nieustalonym.

    Rysunek 3 przedstawia wizualną reprezentację stanów VOL i VIL. Na rysunku 3a poziom VOL jest poniżej progu VIL, więc urządzenie odbierające dane może prawidłowo interpretować stany linii danych/zegara jako niskie. Rysunek 3b pokazuje z kolei poziom VOL jako wyższy niż próg VIL, ale także niższy niż VIH. Linia SDA/SCL na rysunku 3b jest w stanie nieustalonym, co jest niedozwolone w interfejsie I²C. Sygnał może być interpretowany przez urządzenie odbiorcze jako niski lub wysoki, w zależności od konstrukcji stopnia wejściowego urządzenia.

    Debuggowanie I2C z pomocą oscyloskopu
    Rys.3. Przykłady prawidłowego (a) i nieprawidłowego (b) poziomu VOL dla linii SDA i SCL.


    Aby ustrzec się pojawiania się stanów nieustalonych na liniach SDA i SCL, zastosować należy większe oporniki podciągające sieć. Jeżeli ograniczającym je czynnikiem są czasy narastania sygnałów w sieci, wtedy rozważyć można zastosowanie dodatkowych buforów I²C w interfejsie.

    Niezamierzone konflikty transmisji

    Konflikty na liniach omawianego interfejsu pojawiają się, gdy w tym samym czasie załączone są dwa tranzystory FET – jeden typu P, drugi typu N. Jeden z nich podciąga daną linię do góry, do zasilania, a drugi ściąga w dół, do masy. Rezultatem takiej sytuacji jest dosyć wysokie napięcie VOL na linii, które wpada w „szarą strefę” pomiędzy napięciami VIL oraz VIH, definiującymi graniczne napięcia poziomów logicznych. W większości systemów nie jest to poważnym problemem, ponieważ master w sieci ma wejścia pracujące jako otwarty dren i nie może wygenerować takiej sytuacji samodzielnie. Jednakże, w niektórych układach spotkać można inne rozwiązanie, niektórzy wykorzystują układy push-pull jako stopień wyjściowy dla systemów I²C, co już może wygenerować opisany powyżej stan.

    Niezamierzony konflikt jest zazwyczaj łatwy do wyśledzenia na oscylogramie. W takiej sytuacji linie SDA i SCL będą miały bardzo ostre zbocza, z uwagi na mocne podciąganie przez tranzystor FET typu P. Na rysunku 4 master wykorzystuje układ push-pull do sterowania linią SDA z szybkimi zboczami narastającymi. W momencie gdy układ slave wchodzi w stan ACK, aktywnie załączony tranzystor PFET przeciwstawia się tranzystorowi NFET w układzie slave. Generuje to konflikt, opisany powyżej, który powoduje że napięcie w linii jest nieustalone, a prąd płynący przez linię jest wysoki. Może on wzrosnąć na tyle, że będzie mógł uszkodzić tranzystory driverów w układzie.

    Jak widzimy, wyjście typu push-pull słabo sprawdza się w systemach I²C i lepiej nie stosować tego rodzaju driverów do sterowania liniami SDA i SCL.

    Debuggowanie I2C z pomocą oscyloskopu
    Rys.4. Konflikt w dostępie do interfejsu przy wykorzystaniu sterowników push-pull.


    Inną sytuacją, kiedy występuje tego rodzaju konflikt pomiędzy tranzystorem z kanałem typu P i tranzystorem z kanałem typu N, jest aplikacja akceleratorów czasu narastania. Gdy układ taki załączy się w tym samym czasie, co P-FET aktywnie sterujący linią, mamy do czynienia z konfliktem. Pokazany jest on na rysunku 5 – MOSFET typu P aktywnie steruje linią (ustawia ją w stan wysoki), a układ slave, chcąc potwierdzić otrzymanie danych ściąga z pomocą MOSFETa z kanałem typu N linię w stan niski. W ten sposób oba elementy FET – typu N i P – są w tym samym momencie załączone na jednej linii. Konflikt kończy się w momencie, gdy akcelerator czasu narastania zbocza wyłącza się.

    Debuggowanie I2C z pomocą oscyloskopu
    Rys.5. Bufor z akceleratorem czasu narastania impulsu powoduje konflikt w interfejsie I²C.


    Zbyt niska lub wysoka amplituda w stanie wysokim

    Duże skoki napięcia mogą wystąpić, gdy w linii obecna jest duża ilość pasożytniczej indukcyjności lub gdy czas opadania zbocz jest zbyt szybki. Jest to bardziej powszechne w przypadku transmisji kablowych, ale czasami jest obserwowane także podczas transmisji na PCB. Problem z tego rodzaju wahnięciami napięcia polega na tym, że jeśli są one wystarczająco duże, mogą przekroczyć bezwzględne maksymalne napięcie dozwolone na danym pinie (określone w karcie katalogowej danego układu) i spowodować uszkodzenie danego elementu. W wielu przypadkach urządzenie nie ulega awarii natychmiast i może działać nawet po tysiącach takich zawahań napięcia, ale w końcu ulegnie katastrofalnej awarii. Na rysunku 6 zaprezentowano wahanie się napięcia do –0,5 V. Napięcie to przekracza maksymalne dopuszczalne napięcie dla urządzenia, które ma bezwzględny maksymalny dopuszczalny próg równy –0,3 V. Tak duże wahania mogą z czasem spowodować uszkodzenie urządzenia i wymagają korekty w projekcie.

    Debuggowanie I2C z pomocą oscyloskopu
    Rys.6. Zbyt niski sygnał na linii SCL.


    W przypadku zaprezentowanych powyżej zapadów napięcia, jeżeli nie można zwolnić opadania zboczy sygnału (co najłatwiej zrobić małym rezystorem, wstawionym szeregowo w linie sygnałowe), aby zapobiec przekraczaniu przez napięcie dopuszczalnych, bezpiecznych progów można dołożyć przy wejściach diody zabezpieczającej (doskonale sprawdzą się tutaj diody Schottkiego z uwagi na ich szybkość). Pozwoli to na zminimalizowanie skutków przekroczenia dopuszczalnych progów napięcia ujemnego.

    Podsumowanie

    Problemy, które powodują utratę integralności sygnału, takie jak wyższe niż zamierzone napięcia VOL, przesłuchy i zbyt wolne narastanie zboczy, są zwykle łatwe do wykrycia i skutkują tym, że interfejs I²C, w którym master nie otrzymuje potwierdzenia (ACK) są łatwe do debugowania z wykorzystaniem oscyloskopu. Poważne problemy to te, które nie powodują natychmiastowej awarii. Takie problemy mogą wynikać z konfliktów na poszczególnych liniach lub zbyt niskim amplitudom sygnałów, które mogą spowodować awarię urządzeń z czasem działania. Ważne jest, aby być w stanie rozpoznać tego rodzaju problemy z interfejsem I²C, zanim znajdą się one w końcowej aplikacji użytkownika.

    Źródło: http://www.ti.com/lit/an/slyt770/slyt770.pdf

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 napisał 9291 postów o ocenie 6872, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • Tektronix