I2C działa tylko po sondowaniu lub załadowaniu 1Mohm

Próbuję rozwiązać problemy z komunikacją między msp430fr5847 (master) a czujnikiem slave z nieznanym układem I2C (część czujnika przemysłowego)

Mam problemy z nową partią czujników, w których moje dane są zwracane ze wszystkimi zerami, jednak podczas próby rozwiązania problemów z moim Saleae logic pro (2Mohm, 10pf) lub moim oscyloskopem (10Mohm, 50pf) system działa idealnie podczas sondowania pin SDA.

Dalsze rozwiązywanie problemów obwód działa poprawnie, jeśli dodam rezystor 1Mohm między SDA a masą, ale nie działa, jeśli dodam tylko kondensator 10pf lub 100pf.

Używam rezystorów podciągających 4,7k do mojej szyny 3.3v.

Co może być przyczyną tego problemu i co można zrobić, aby rozwiązać problem bez przypadkowego rozwiązania problemu.

EDYCJA: 19/07/2017 Oto krótki ślad moich sygnałów.

Coś innego, o czym zapomniałem wspomnieć, to że tylko sondowanie SDA powoduje, że płyta działa, sondowanie SCL lub moja linia przerwań nie działa prawidłowo.

EDYCJA: 21/07/2017

Fabuła gęstnieje, wydaje się, że podłączenie innego oscyloskopu nie powoduje prawidłowego działania obwodu i widać, że jedyną różnicą jest to, że ACK nie jest przesyłany.

Na powyższym zdjęciu, niebieskie i zielone ślady to SCL i SDA, gdy obwód nie działa poprawnie. Żółte i różowe ślady pochodzą z tego, kiedy również podłączam logikę Saleae do pinu SDA i uziemienia, ale bez podłączania USB (starając się uniknąć pętli uziemienia).

Aby dodać nieco więcej tła czujnika, jest to przemysłowy czujnik ciśnienia, który kupujemy od producenta. Wcześniej zaprojektowaliśmy i przetestowaliśmy te płytki z naszą pierwszą serią czujników. Niedawno otrzymaliśmy nową partię i mamy teraz do czynienia z tymi problemami. Przeprowadziłem trochę dochodzenia i mocno podejrzewam (po przejrzeniu unikatowo wyglądających zdań z arkusza danych), że wewnętrznie czujnik wykorzystuje ZSC31014 lub podobny arkusz danych PDF TUTAJ

EDYCJA: 26/07/2017

Mam więc nadzieję, że ostatnia część w rozwiązaniu tego problemu, zgodnie ze szczegółową odpowiedzią SamGibsona, wdrożyłem poprawkę ustawiania wysokiego bitu adresu w celu maskowania usterki na końcu bitu początkowego.

Działa to głównie z danymi przychodzącymi zgodnie z oczekiwaniami, jednak teraz wydaje się, że w pierwszym poleceniu odczytu po zapisie (jeśli jest to poprawny termin dla grupy bitów i2c), urządzenie podrzędne próbuje ACK o bit nieco wcześniej (w pozycja bitu zapisu). Mogę powiedzieć, że to niewolnik ciągnie linię w dół, dodając mały rezystor (47 omów) szeregowo z linią SDA.

Zwykle zaczynam to jako nowe pytanie, ale kiedy dołączam ten sam zakres, który nie miał żadnego wpływu na powyższe rozwiązywanie problemów, ten problem wydaje się znikać, to naprawdę wydaje się być problemem granicznym, ponieważ nawet jeśli podłączę sondę zakresu, bez połączenia go z zakresem problem został rozwiązany, więc zakładam, że jest to problem z pojemnością.

Działka bez dołączonego zakresu

Wykres problemu z podłączoną sondą zakresu, ale nie podłączoną do lunety, odnotowującą nieco wyższe napięcie, gdy slave ściąga bit zapisu zamiast bitu ACK.

I pomyśleć znalazłem odpowiedź. Okazuje się, że jest to znany problem, ale odkryłem, że po tym, jak zdecydowałem, gdzie jest problem, i szukałem go!

Oto proces, przez który przeszedłem, abyś mógł go śledzić (i, jeśli to konieczne, możesz dostosować swoje dochodzenie, jeśli zobaczysz wyniki, które różnią się od moich założeń). Najważniejsze jest to, że wydaje się, że istnieje niezgodność między (przynajmniej niektórymi) zachowaniami I²C MSP430 i wymaganym zachowaniem I²C przez urządzenie, które podejrzewasz, że jest Slave I²C, IDT ZSC31014 . Posiadanie arkusza danych dla tego urządzenia ma kluczowe znaczenie dla zrozumienia tego, więc dziękuję za znalezienie go.

Dobra wiadomość jest taka, że ​​istnieją (przynajmniej) 2 obejścia tego problemu, które wyjaśnię na końcu.

Fabuła gęstnieje, wydaje się, że podłączenie innego oscyloskopu nie powoduje prawidłowego działania obwodu i widać, że jedyną różnicą jest to, że ACK nie jest przesyłany.

Nowe ślady są pomocne, dziękuję, chociaż interpretuję je nieco inaczej.

(Przerwa sygnału SCL, która dotyczyła mnie w początkowym zapisie, jest nadal obecna w najnowszym zapisie. Interesujące jest to, że przesunięcie w SCL wydaje się większe niż przesunięcie w SDA, szczególnie biorąc pod uwagę różne skale pionowe między sygnałami SCL i SDA w najnowszy ślad. Wciąż sugerowałbym zbadanie, czy SCL nie osiąga końca, ale nie sądzę, aby miało to związek z głównym problemem).

Są te dwie „usterki” w SDA:

• Usterka tuż przed lub tuż po impulsie ACK nie jest rzadkością, gdy I²C Master zwalnia kontrolę SDA, aby umożliwić Slave wykonanie ACK, a następnie Master może ponownie uruchomić SDA. Dlatego go ignoruję.

• Jest to wczesna usterka SDA, przed pierwszym impulsem SCL, co jest bardziej niezwykłe. Z amplitudy tej wczesnej usterki SDA (patrz później) i faktu, że występuje ona tylko przed pierwszym impulsem SCL (oznaczonym jako 0), ale nie występuje przed późniejszymi impulsami SCL, w których moglibyśmy zobaczyć usterkę na SDA (jak SCL impulsy oznaczone 4, 5, 6 lub 7), wiemy, że nie jest to artefakt pomiarowy ani sprzężenie z SCL (na przykład).

(Dla późniejszego odniesienia, wczesna usterka SDA wygląda jak co najmniej 2 V w najnowszym śladzie, więc przy Vdd przy 3,6 V z wcześniejszych komentarzy, co sprawia, że ​​amplituda usterki SDA wynosi co najmniej (2 / 3,6) = 0,55 x Vdd. Porównaj to z odpowiednie progi poziomu logicznego I2C omówione później.)

Ignorując różnicę ACK, uważam, że widzę kolejną różnicę między dwoma zestawami śladów na tym drugim zrzucie ekranu. Amplituda tej wczesnej usterki SDA wydaje się nieco inna, porównując górny ślad SDA oznaczony C1(żółty izh?) I drugi ślad SDA oznaczony M3(niebieski). Wierzę teraz, że różnice w amplitudzie tej wczesnej usterki SDA mogą spowodować pojawienie się lub zniknięcie problemu, jak wyjaśnię poniżej.

Pomogłaby jeszcze większa rozdzielczość, szczególnie w przypadku usterki (jest to jeden z problemów w próbie pracy nad problemami „zdalnie” - sam nie mogę obsługiwać lunety!). Zakładam, że kiedy powiększasz, wygląda na to, że zaczyna się normalna logika I²C „1” (tj. Krzywa RC na zboczu narastającym, szczególnie jeśli chwilowo osłabiasz podciągnięcia, np. 10k), ale nie robi to „ t osiągnąć pełne napięcie dodatnie, zanim zostanie ponownie doprowadzone do logicznego „0”. To jest pokazane na innej stronie, do której link został później dołączony. Jeśli widzisz inny kształt niż usterka, moja późniejsza analiza może nie mieć zastosowania.

I²C Master kontroluje magistralę w punkcie usterki, między I²C Start a pierwszym impulsem zegarowym SCL (który oznaczono jako „0”, chociaż jest to MSbit). To spowodowało, że zacząłem podejrzewać zachowanie MSP430, chociaż przy niskim SCL w tym momencie usterka SDA nie powinna wpływać na urządzenia zgodne z I²C, ponieważ będą czekały na wysoki poziom SCL, zanim ponownie odczytają stan SDA.

Czy więc IlaC Slave jest naprawdę zgodny z I²C? Okazuje się, że ZSC31014 jest „ wybredny ” i mniej tolerancyjny niż niektóre inne urządzenia I²C, dokładnie w momencie, gdy uważam, że MSP430 produkuje tę usterkę!

W ZSC31014 datasheet wymienia 3 obszary, w których przyznają I²C zachowanie urządzenia jest „inny”. Dwa pierwsze na tej liście mogą Cię również dotyczyć w innych momentach (nie jest to częścią tej analizy), ale jest to trzeci punkt, który zaznaczyłem poniżej na czerwono, związany z tą wczesną usterką SDA:

Amplituda tej wczesnej usterki SDA ma kluczowe znaczenie . Jeśli ta usterka nie podniesie się wystarczająco, aby ZSC31014 rozpoznał ją jako logiczną „1”, zanim ponownie spadnie, oznacza to, że wszystko jest w porządku - urządzenie musi zobaczyć opadającą krawędź SDA, aby złamać tę „regułę” i może być tylko spada krawędź, jeśli został już uznany za logiki „1”.

Wszystko, co wpływa na amplitudę usterki SDA, takie jak dodatkowe obciążenie lunety lub analizatora logicznego na sygnał SDA, może wystarczyć, aby usterka została rozpoznana przez ZSC31014 jako osiągająca logiczną „1”, a zatem nie „spadającą” SDA edge ”, ten trzeci punkt na liście, może wystąpić (w dobry dzień, w zależności od napięć, temperatur itp.). Jednak, jak odkryłeś, różnica między różnymi oscyloskopami wystarcza, aby niektóre z nich dodawały wystarczające obciążenie, aby zatrzymać problem, a inne nie. Ta konfiguracja musi być bardzo marginalna!

Potwierdza to moje obawy, że wcześniejsze „działające” partie czujników mogą działać „tylko”, ponieważ MCU MSP430 w tych „działających” konfiguracjach prawdopodobnie będą również powodować usterki SDA. Moja teoria na temat możliwej różnicy między partiami czujników, która mogłaby wyjaśnić różne zgłaszane zachowanie (partia „działająca” vs. partia „niedziałająca”) została wyjaśniona poniżej.

Co ciekawe, ZSC31014 różni się od standardowego I²C w innym obszarze, który nie jest wymieniony na tej liście od producenta, i to może wyjaśniać, dlaczego widzisz różnicę między partiami czujników.

Standardowe progi logiczne I²C są (uproszczone) - poniżej 0,3 x Vdd dla logiki „0” i powyżej 0,7 x Vdd dla logiki „1”, jak pokazano w specyfikacji I²C :

Jednak ZSC31014 ma różne progi, 0,2 x Vdd i 0,8 x Vdd, co oznacza, że ​​jego „niezdefiniowany region” między tymi progami jest większy niż typowe urządzenia I²C:

Ten większy „nieokreślony region” zwiększa szansę, że usterka wejdzie w nieokreślony obszar poziomu napięcia, gdzie może zostać rozpoznany jako logiczne „1” (pamiętaj, że wszystko powyżej 0,2 x Vdd może być rozpoznane przez ZSC31014 jako logiczne „1” , ponieważ w nieokreślonym regionie wszystko jest dozwolone - jest tylko powyżej 0,8 x Vdd, kiedy musi być rozpoznane jako logiczna „1”). I, jak wyjaśniono wcześniej, jeśli usterka zostanie rozpoznana przez ZSC31014 jako osiągającą logikę „1”, to kiedy ponownie spadnie do logiki „0”, złamałeś tę „regułę” zaznaczoną na czerwono dla wymaganego zachowania I²C przez ZSC31014.

Ponieważ rozpoznanie poziomów logicznych w tym „niezdefiniowanym” obszarze napięcia nie jest określone, producent czujnika nie łamie specyfikacji, jeśli wykona jedną partię, która rozpoznaje logikę „1” tylko, gdy osiągnie 0,7 x Vdd, ale utworzy kolejną partię, która rozpoznaje na przykład logiczne „1” tak niskie, jak 0,4 x Vdd. Ta hipotetyczna druga partia byłaby bardziej skłonna postrzegać usterkę SDA jako opadającą krawędź SDA, z naruszeniem tego trzeciego punktu na liście, ale nie naruszając specyfikacji.

(Wiele problemów, nad którymi pracowałem przez lata, wyglądało tak: Są dwa urządzenia, z których żadne nie łamie specyfikacji zawierającej luki - ale jedno jest wybredne i mniej tolerancyjne, w punkcie, w którym drugie wymaga, aby podłączone urządzenia były bardziej tolerancyjne ze względu na ich niejasne zachowanie! Każde z tych dwóch urządzeń doskonale współpracuje z większością innych urządzeń, ale jest zawodne (lub całkowicie zawiesza się), gdy są ze sobą połączone.)

Więc co możesz zrobić? Myślałem o dwóch opcjach:

• Nie używaj MSP430 - użyj innego MCU, który nie tworzy wczesnego usterki SDA. Jednak spodziewam się, że zainwestowałeś dużo czasu w oprogramowanie i nie chciałbym przenosić kodu do innego MCU, jeśli można tego uniknąć.

• „Bit-bang” protokół I²C na MSP430, zamiast korzystania z wbudowanego modułu sprzętowego I²C. W ten sposób masz całkowitą kontrolę nad sygnałami I²C i możesz zapobiec wystąpieniu tej usterki. Jednak oczywiście byłoby trochę pracy nad stworzeniem własnych procedur I²C, debugowaniem ich, a wynikowy kod może być większy niż przy użyciu modułu sprzętowego MSP430 I²C, co samo w sobie może stanowić problem, jeśli brakuje Ci przestrzeni Flash.

Potem zacząłem szukać problemów z MSP430 I²C i odkryłem, że ta kombinacja MSP430 + ZSC31014 jest znanym problemem ze względu na tę wczesną usterkę SDA z MSP430! Zobacz ten wątek na forum TI E2E MSP430:

Forum TI E2E: impulsy usterki MSP430 I2C powodują problemy z układem peryferyjnym I2C

Obejście wspomniano tam, jest zmiana adresu ZSC31014 I²C tak że SDA jest wysoki w momencie, gdy dodatni usterka mogłaby wystąpić, a ponieważ SDA jest wysoki wtedy i tak nie ma faktycznej usterki na SDA:

Naszym obejściem jest skonfigurowanie układu ZSC, aby miał adres z ustawionym bitem 6 (np. Używamy teraz 0x42) - zamienia to impuls usterki w ładny czysty „wysoki” bit na czas trwania bitu adresu 6, który się pozbywa problematycznego opadania krawędzi.

To samo obejście jest w rzeczywistości odwrotnością sugestii w arkuszu danych ZSC31014, w czerwonym polu, które zaznaczyłem. Mówią, że usterce SDA należy zapobiec, jeśli pierwszy bit (który jest MSbit) adresu ISCC ZSC31014 ma wartość 0 - więc nie ustawiaj MSbit adresu I²C na „0”, zamiast tego na „1”, tj. ustaw bit 6 w 7-bitowym adresie I²C!

Ponieważ zarówno wątek forum TI E2E, jak i arkusz danych ZSC31014 koncentrują się na adresie I²C, być może albo usterka SDA nie występuje, albo nie stanowi problemu, jeśli wystąpi, podczas wysyłania innych danych do magistrali. Musisz to zbadać.

Dlatego ignorując pierwsze obejście używania innego MCU, dwa (bardziej praktyczne) obejścia to:

• Uderz w magistralę MSP430 I²C, pisząc własny kod, abyś nie stworzył tej usterki na SDA lub
• Zmień adres ISCC ZSC31014 tak, aby bit 6 jego 7-bitowego adresu został ustawiony, co oznacza, że ​​SDA jest już wysoki, gdy usterka wystąpiłaby inaczej, więc nie ma rzeczywistej usterki na SDA, gdy adresowany jest ZSC31014 (zakładając, że usterka SDA nie występuje po innych zdarzeniach I²C Start podczas przesyłania danych lub jeśli wystąpi, że ZSC31014 się nie denerwuje).

Mam nadzieję, że to pomaga!