Problem z komunikacją z czujnikiem Honeywell z serii ASDX-DO

[danioto]

Witajcie,

czy ktoś ma doświadczenie w obsłudze czujników ciśnienia z serii ASDX-DO z firmy Honeywell i chciałby się podzielić doświadczeniami?

Zacznę może od tego, że nota katalogowa czujnika jest w opłakanym stanie. Na temat komunikacji z czujnikiem po I2C jest napisane jedno zdanie w przypisach, które trzeba interpretować, a jak dla mnie notę katalogową, którą trzeba interpretować można od razu wyrzucić do kosza. Tutaj znajduje się link do dokumentacji całej serii.

Z drugiej strony znalazłem również wskazówki dotyczące interfejsu I2C w czujnikach Honeywell: TUTAJ.

W każdym razie zrozumiałem, że adres urządzenia 0xF0 należy bitowo zsumować z komendą zapisu 0x01, jednak dla obu przypadków nie miałem nawet potwierdzenia odbioru adresu, które według wskazówek I2C powinno wystąpić. W każdym razie stwierdziłem, że może jednak źle rozumiem notę katalogową i zrobiłem prosty program skanujący wszystkie dostępne adresy I2C i nie wykryło nic. Kolejnym moim wnioskiem było możliwe uszkodzenie czujnika, ale po wymianie na nowy dalej nic nie potwierdza. I już zaczyna mi braknąć pomysłów. Czy macie jakieś wskazówki co jeszcze może nie działać?

Sama obsługa I2C jest raczej poprawna, ponieważ mam jeszcze BMP085 na tej magistrali i wszystko ładnie hula. Zasilanie czujnika też raczej jest spoko, bo to tylko 5 pinów. Wszystko posprawdzałem jeszcze oscyloskopem dla pewności i faktycznie, układ nie żyje. Pomóżcie proszę, bo już mi się pomysły kończą...

Daniel

[mi14chal]

A schemat podłączenia? Nie pomyliłeś pinów?

[danioto]

A schemat podłączenia? Nie pomyliłeś pinów?

Właśnie pisałem, że "Zasilanie czujnika też raczej jest spoko, bo to tylko 5 pinów. Wszystko posprawdzałem jeszcze oscyloskopem dla pewności i faktycznie, układ nie żyje." Sprawdzałem już chyba z 10 razy, więc raczej jestem pewien, że jest dobrze.

Jak już jesteśmy przy pinach, to mam od razu pytanie (bo oczywiście producent nie pomyślał, by pokazać schemat wewnętrzny czujnika) odnośnie Vout, czy macie jakiś pomysł co to za pin?

[marek1707]

A czy ten sam program wykrywający obecność czegoś nowego na I2C wykrywa dotychczasowy układ? Może coś tam jest skopane? Może Honeywell nie wykrywa Repeated Start a Ty nie robisz np. Stop po NAK? Czy jakoś ten program testowałeś na czymś dobrze działającym?

Mogłeś też odwrotnie podłączyć czujnik - w sensie stron układu. Jedynka powinna być zaznaczona, ale w zależności od wykonania może być po innej stronie. Czy bierze z z zasilania jakiś sensowny prąd?

W ten adres 0xF0 to bym za bardzo nie wierzył (są też inne błędy w tym dokumencie) bo w I2C jest on zarezerwowany do adresowania rozszerzonego.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[danioto]

O! To już konkretne możliwe przyczyny! Już się odnoszę:

1) Ten mały programik do skanowania wykrywa bez problemu BMP085, ale nie wykrywa obu czujników Honeywell.

2) Psudokod programu:

for (help_address=0; help_address<0xFF; help_address++)
{
GenerateSTART();
WaitForEV5();
SendAddress(help_address);
Wait(1ms);
if (bit ADDR in I2C1->SR1) break;
GenerateSTOP();
Wait(1ms);
}

Od razu wyjaśniam: pierwszy wait jest dla określenia timeoutu odpowiedzi, a drugi dla poczekania zanim wyzwoli sie kolejny start. Bit ADDR w rejestrze SR1 w STM32 jest ustawiony wtedy, jak adres urządzenia został wysłany (czyli wnioskuję, że został odebrany ACK po wysłaniu). Mówisz Marku, że tu może być jakieś błędne rozumowanie?

3. Piny są faktycznie dziwnie numerowane, ale tak jak mówiłem, sprawdzałem z notą katalogową już kilka razy. Zastanawiam się tylko nad wyjściem Vout, bo nie widzę żadnej informacji, czym ono może być.

4. Prądu faktycznie nie sprawdziłem. To dobry pomysł i jutro od tego zacznę.

5. Hmm, o tym adresie 0xF0 to nawet nie wiedziałem. W specyfikacji I2C to wyczytałeś? Czy 0xF1 też jest w jakiś sposób zarezerwowany?

Dawno nie wiedziałem tak słabej dokumentacji. Tego czujnika używają pewnie sami desperaci (na przykład ja 😋). Dzięki za zainteresowanie i odpowiedź, jakby coś jeszcze Ci do głowy wpadło to daj znać, bo mi się pomysły powoli kończą..

[marek1707]

http://www.i2c-bus.org/addressing/10-bit-addressing/

[danioto]

Dopiero teraz się zorientowałem, że mówisz o adresowaniu 10bit 🙂

Hmm, dopiero teraz zauważyłem, że na nóżce SCL mam 2.7V, kiedy cały układ działa na 5V, to chyba jednoznaczny dowód na to, że układ jest do kosza, prawda? Najlepsze jest to, że wlutowałem nowy, miałem na SCL 4.8V, a po chwili znowu 2.7... Schemat jest tak prosty, że aż boli, więc zupełnie nie rozumiem skąd ta zmiana napięcia...

[marek1707]

Jakie masz rezystory podciągające do Vcc? Do jakiego napięcia ciągną?

Może układ ma tak marne wyjścia, że "nie ma siły" zrobić prawdziwego 0V?

Czy STM jest zasilany z 3.3V i czy jest wprost podłączony do tej szyny I2C?

[MirekCz]

Schemat? Płytka? Zdjęcia złożonego układu?

[danioto]

Rezystory 6k8 podciągające do 5V. Piny od I2C w STM są 5V tolerant, więc ze strony STM nie powinno być problemu, chyba, że ze strony układu jest problem z wykryciem SCL'a, jeżeli ten śmiga na 3V3. To by w sumie wszystko tłumaczyło. Powinienem zastosować konwerter poziomów napięć lub zrobić pullup do 3V3? Z tego co pamiętam już pracowałem z czujnikami działającymi na 5V i bez problemu komunikowały się z STMem.

Nawet gdyby układ nie dał rady ściągnąć linii danych do masy, to na oscyloskopie widziałbym, że próbuje, a tam nie ma najmniejszej zmiany stanu.

Załączam profesjonalny schemat blokowy z paint'a:

[MirekCz]

Oczekujesz pomocy czy wróżenia z fusów?

Jak mam z tego sprawdzić czy dobrze podłączyłeś czujnik?

[marek1707]

Jeśli nie korzystasz z jakiejś biblioteki tylko sam to pisałeś, to moim zdaniem coś jest źle w okolicy ACK.

Nie jestem dobry w STM-ach, ale po szybkim przejrzeniu manuala widzę, że ST proponuje następującą sekwencję podczas adresowania urządzenia I2C w trybie Master Transmitter:

1. Wysłanie zdarzenia START poprzez ustawienie bitu START w CR1.

2. Oczekiwanie na SB=1 w SR1.

3. Zapis adresu Slave'a do DR (dokończenie sekwencji EV5).

4. Odczyt SR1 i SR2 (sekwencja EV6) a w niej:

4a. Sprawdzenie czy ADDR=1 czyli oczekiwanie na wysłanie adresu

4b. Sprawdzenie w tym samym SR1 stanu bitu AF. Jeżeli ustawiony, zabrakło ACK

i dalej to już łatwo...

Piszą też, żeby po każdym NAK wysyłać STOP (sekwencja EV8_2 z odpowiednimi warunkami), co powoduje powrót interfejsu do stanu początkowego.

Osobiście nie podoba mi się to oczekiwanie 1ms - masz od tego odpowiedni bit statusu (ADDR) a poza tym jego ustawienie to dopiero sygnalizacja wysłania adresu. To AF jest flagą błędu NAK.

Ponieważ niektóre sekwencje wymagają dostępu do więcej niż jednego rejestru a blok I2C naprawdę oczekuje wykonania pełnych sekwencji, powinny być one wg mnie zamknięte w sekcjach krytycznych tj. blokujących przerwania.

[danioto]

Oczekujesz pomocy czy wróżenia z fusów?

Jak mam z tego sprawdzić czy dobrze podłączyłeś czujnik?

Szczerze powiedziawszy, zawsze interesowały mnie sztuki magiczne.

Wracając do tematu, dobrze piszesz Marku, zmienię sekwencję skanowania sieci według dokumentacji i dam znać Dzięki za wskazówki 🙂

[ Dodano: 22-01-2014, 21:02 ]

Hmm, chyba Marku się nie do końca zgodzę z tym co napisałeś, bo w opisie rejestrów I2C jest napisane przy ADDR:

Address sent (Master)
0: No end of address transmission
1: End of address transmission
-For 10-bit addressing, the bit is set after the ACK of the 2nd byte.
-For 7-bit addressing, the bit is set after the ACK of the byte.
Note: ADDR is not set after a NACK reception

Czyli jeżeli po jakimś czasie oczekiwania w ADDR jest 0 to znaczy, że nie było ACK. Czekanie też mi się nie podoba, ale póki co nie wczytywałem się bardziej w RM, by to czymś inteligentniejszym zastąpić.

W każdym razie chciałbym poruszyć jedną kwestię: stanów napięciowych na liniach SDA oraz SCL, ponieważ mam na nich różne napięcia... Na ząłączonym obrazku widać, że na SDA mam 5V, a na SCL około 3.8 bez żadnego ruchu na magistrali. Czy to nie oznacza, że mam spalone wejście SCL? Po podciągnięciu obu linii do 5V powinienem mieć około 5V na liniach, prawda?

[MirekCz]

W każdym razie chciałbym poruszyć jedną kwestię: stanów napięciowych na liniach SDA oraz SCL, ponieważ mam na nich różne napięcia... Na ząłączonym obrazku widać, że na SDA mam 5V, a na SCL około 3.8 bez żadnego ruchu na magistrali. Czy to nie oznacza, że mam spalone wejście SCL? Po podciągnięciu obu linii do 5V powinienem mieć około 5V na liniach, prawda?

To może oznaczać cały szereg rzeczy - od źle ustawionych pinów w procesorze, poprzez źle wlutowane / dobrane rezystory po złe wlutowany układ czy źle prowadzone ścieżki (do nie tych pinów co trzeba). Układ raczej się nie pali tak od siebie jak był dobrze połączony, a wg. Twojego opisu coś dziwnego jednak się dzieje.

Dlatego od początku pytam o porządny schemat i rysunek + zdjęcie płytki (połączeń pinów), ale kolega problemu szuka na końcu (transmisja I2C) zamiast na początku (dziwne napięcia na pinach)

PS. Złap przebieg transmisji I2C na oscyloskopie. On też może być całkiem ciekawy jak tam wisi jakieś obciążenie (np. inny czas narastania / opadania tego obciążonego sygnału w porównaniu z tym nieobciążonym)

[marek1707]

Tak, to niskie napięcie na SCK też mi się nie podobało, ale uznałem, że to i tak jest więcej niż potrzeba by układ 5V widział stan wysoki i uznałem to za problem drugiej kategorii. Te 3.8V wygląda na złe ustawienie trybu pracy pinu procesora. Jeśli nie jest to czysty open drain to np. załączony pull-up może trochę ściągać linię w stronę swojego Vdd, bo robi się dzielnik z dwóch rezystorów rozpiętych między 5V a 3.3V.

Nie wnikałem w szczegóły schematu, bo nie można każdego traktować jak osła. Przecież Kolega danioto robił już w I2C i swoje doświadczenie ma, a ew. odwrotne podłączenie całego czujnika wykryje i bez nas.

Będąc upartym (osłem?) i krążąc wokół I2C to tak, niezapalenie się ADDR rzeczywiście oznacza niewysłanie adresu a po pewnym czasie także brak ACK, ale bądźmy szczerzy, chyba wyrośliśmy już z timeoutów w funkcjach, gdzie odpowiedni bit statusu aż prosi się o sprawdzenie (i zgłasza odpowiednie przerwanie!). Wydało mi się naturalne skorzystanie z AF:

Bit 10 AF: Acknowledge failure

0: No acknowledge failure

1: Acknowledge failure

–Set by hardware when no acknowledge is returned.

–Cleared by software writing 0, or by hardware when PE=0.

No dobra, zdaje się, że taki czy inny test adresów na I2C i tak wykrywa dotychczasowy czujnik a nie widzi Honeywell'a. Wymuszasz STOP po każdym NAK? Co z prądem zasilania?

Obrazki z transmisji - choćby samego adresu - pewnie sam już oglądałeś i gdyby coś było zastanawiająco źle to byś coś sam zapodał. W każdym razie jeśli możesz to złapać, podeślij.

Wyjście Vout to może być analogowe wyjście napięciowe - w każdym razie ja bym tak zrobił 🙂 skoro i tak gdzieś w środku scalaka taki sygnał jest. Albo to jakieś wewnętrznie generowane napięcie potrzebne do pracy układu. Mierzyłeś to? Spełniłeś wymagania spod tabelki? Kondensator na zasilaniu i na Vout a wszystkie N/C naprawdę są niepodłączone? Wiem, że to ma się nijak do działania I2C i powinno odpowiadać ACKiem bez łaski.