Raspberry Pi Padła malina

@szmydu Moim zdaniem mógł to być całkowity przypadek. Ten PMIC ma złą sławę i ludziom potrafił padać od krzywego spojrzenia na PCB 😉 

Początkowo była nawet akcja serwisowa i wszystkim wymieniali płytki z jakąś tam wersją tego układu na nowe. Potem wymieniali tym, którym się uszkodził nawet po gwarancji. Jeśli masz RPI kupione z oficjalnej dystrybucji, to napisz do sklepu i do wsparcia RPI Foundation, bo może to dalej obowiązuje i Ci wymienią gratis. 

Rpi po gwarancji więc na wymianę raczej bym nie liczył. Jedno jest pewne, że dla bezpieczeństwa czujniki DS, DHT22 i kontaktrony muszę przenieść z GPIO maliny na arduino, aby malina tylko zajmowała się domoticzem. Znalazłem już na tym forum gotowy szkic dla DS18b20 i dla kontaktronów. Pytanie czy ma ktoś może dla DHT22 ? 

No dobrze, wziąłem dwie maliny i pobawiłem się trochę.

Wersja 3B+ jest bardzo przyjazna bo szyna I2C układu PMIC jest łatwo dostępna na PP60 (SDA) i PP59 (SCL). Na wersji 4 już tak łatwo nie jest.

Łączymy PP60 pierwszej do GPIO8 drugiej oraz PP59 do GPIO9 odpowiednio.

Pomimo, że możliwe jest podłączenie samo na siebie (na jednej malinie), to nie powinni się tak robić, bo niektóre rejestry nie mogą być zmieniane w locie i po wysłaniu komendy PMIC robi szybki restart.

Na drugiej uruchamiamy np Rasbian i włączamy I2C w raspi-config.

W terminalu drugiej piszemy:

pi@raspberrypi:~ $ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- 1d -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- 43 -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --       

I widzimy, że nasz PMIC jest na adresie 0x1d, czyli inaczej niż w specyfikacji fabrycznej. Ciekawe, że jak ponownie uruchomiłem pierwszą malinę to PMIC pojawił się na adresie 0x1b, więc nie dziwcie się jak będzie tak u Was.

Potem odczytujemy rejestry:

pi@raspberrypi:~ $ sudo i2cdump 1 0x1D 
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x1d, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: a0 01 e4 27 43 57 27 00 00 00 02 00 XX XX XX XX    ???'CW'...?.XXXX
10: a5 a5 5a c0 c0 e4 1f 48 10 a9 5f 73 00 00 XX XX    ??Z????H??_s..XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX

Po chwili stresu mamy wynik, który możemy sobie zrzucić do pliku np.:

sudo i2cdump 1 0x1D > rpi3bplus.txt

I to są wartości z poprawnie działającej maliny w wersji 3B+. 

Gdy kilka lat temu kupiłem surowy układ, to posiadał on tylko uruchomione wyjście LowDrop, a pozostałe wyzerowane.

Wersja A posiada inne zapisane wartości napięć i sekwencji uruchamiania. Poniżej zrobiłem porównanie:

Adres  Wartość Wartość	Wartość		Znaczenie		Różnice
rej.   domyśl. RPi3B+	Dekodow
0x01	0x01	0x01	Włącz 		Przetwornik cyfrowo-analogowy
0x02	0xe4	0xe4	1>2>3>4		Przeplot faz B1 > B2 > B3 > B4
0x10	0xa5	0xa5	3,30V		Napięcie wyjścia LowDrop
0x11	0xa5	0xa5	3,30V		Napięcie wyjścia B1
0x12	0x5a	0x5a	1,80V		Napięcie wyjścia B2
0x13	0xd8	0xc0	1,20V		Napięcie wyjścia B3	1,20V zamiast 1,35V!!! 
0x14	0xc0	0xc0	1,20V		Napięcie wyjścia B4
0x15	0xf9	0xe4	B1>B2>B3>B4	Włączane sekwencyjnie	Inna kolejność!!!
0x16	0x1f	0x1f	L>+++++		Włączone kanały L+1-4
0x17	0X44	0X48	PG1-B3		PG1 monitoruje B3	Inne przypisanie!
0x18	0x1a	0x10	PG2-B4		PG2 monitoruje B4	Inne przypisanie!
0x19	0xe9	0xa9	Chip, no disch. Błąd resetuje cały układ Inne zachowanie!
0x1a	0x7f	0x5f	Under voltage	Wskazuj poniżej 4,63V	Inne zachowanie!

Stany tylko do odczytu
0x00	0xa0	0xa0	1,6		Wersja układu
0x1b	---	0x73	23C		Temperatura
0x1c	---	0x00	0V
0x1d	---	0x00	0V

Rejestry od 0x03 do 0x0b to jakieś śmieci nieopisane w dokumentacji układu.

Czyli jeśli kupimy wersję A, to ryzykujemy, że zasilimy rdzeń napięciem 1,35V zamiast 1,2V, co może być niezdrowe dla maliny, więc nie uruchomi się wcale, bo również sekwencja napięć jest inna.

Wersja X ma napięcie rdzenia 0,85V więc malina się na pewno nie uruchomi, ale też nie narażamy jej na zbyt wysokie napięcie.

Żeby zmienić stan rejestru należy wydać komendę np.:

sudo i2cset 1 0x1D 0x13 0xC0

Czyli zmiana napięcia B3 na 1,2V. Każdą kolejną zmianę trzeba robić po kolei.

Kolega @szmydu przesłał mi nieszczęsną Raspberry, która zainicjowała ten temat. Cała płyta pobierała tylko 15-25mA czyli praktycznie tyle co czerwona dioda LED. Pobór się wahał, więc PMIC coś próbował walczyć, ale po I2C nie dawał śladu życia. Nie było żadnych napięć wyjściowych, więc podjąłem decyzję, że czas na wymianę. Zakasałem rękawy, lufa, żeby się ręce nie trzęsły i jazda!

Oto winowajca.

Tu są zaznaczone pola testowe, na których powinna występować komunikacja I2C. Obie linie powinny być podciągnięte do +3,3V przy poprawnej pracy Raspberry.

Sam układ nie wskazywał na jakiekolwiek oznaki przegrzania, zimnych lutów, ani innych podejrzanych zjawisk.

Po chwili grzania, i jeszcze dłuższej chwili, na pogrzewaczy i hot-airem, ... wreszcie udało się go wyrwać. Jak ja nie lubię lutowania bezołowiowego!!!

Nowy układ dostarczony przez @szmydu był nawet niepobielony, więc musiałem przygotować pady - oczywiście ołowiówką 🙂

Dzięki cynie ołowiowej wlutowanie to była przyjemność!

Podłączone zasilanie i Raspberry PMIC ruszyło od strzała! Wygląda na to, że zakupiona wersja była wstępnie zaprogramowana, bo napięcia są poprawne. W tym momencie musiałem przerwać, ale wieczorem odczytam co jest w pamięciach i spróbuję uruchomić jakiś system. 

No i sprawdziłem wieczorem i jest lipa. PMIC nieobciążony generuje niby poprawne napięcia, ale z kartą dzieją się cuda. Napięcia wariują i malina nie wstaje.

Sprawdziłem stany rejestrów i są niepoprawne, takie:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    
00: a0 01 a0 01 43 57 43 57 a0 01 a0 01 XX XX XX XX  
10: a5 a5 a5 a5 c0 e4 c0 e4 a5 a5 a5 a5 c0 e4 XX XX 

A co gorsze, to te wartości mają się nijak do zachowania układu, bo np. 0x12 przy wartości 0xa5 nie powinno być 1,8V, a jednak jest. Podobnie 0x13 jest 0xa5, a napięcie 1,2V. Jakiś kosmos!

Na domiar złego jakakolwiek próba modyfikacji którejkolwiek wartości nie ma sensu, bo zmienia się losowo kilka rejestrów, a napięcia i tak pozostają bez zmian. Po restarcie układu wszystko wraca do stanu pierwotnego.

Wygląda na to, że zakupiony przez właściciela układ to jakaś podła podróba, której nie można reprogramować.

Jeszcze powalczę, ale wniosek na gorąco jest taki, że jednak lepiej kupić oryginalny, surowy układ (bez żadnych literek) lub wersję oficjalną A, to mamy szansę sobie ją ustawić jak oryginał, a tak.... lipa.

Wygląda na to, że trafił się przypadek, przed którym przestrzegał @isom 

Niestety z tymi PMIC to jak pisałem loteria i nie ma reguły co chińczyk oznaczy A czy R . Ten post kolegi @_marss_ jest fajnym poradnikiem i jednocześnie przestrogą dla innych. Teraz kiedy ceny raspberry poszybowały w kosmos , naprawdę dobrze jest pomyśleć o jakimś terminalu HP T620 lub DELL Wyse . Mam przećwiczone oba modele i bardzo fajnie to działa. W HP trzeba aktualizować bios bo nie rusza bez monitora na wersjach starszych niż 2019 , ale to nie jest fizyka jądrowa . Po godzinie  zabawy system działa bez monitora z autostartem po zaniku zasilania i Ubuntu 20.04 na dysku SSD M2 - przeznaczony do trudnych warunków pracy.

jak by co to mam gdzieś Malinkę z uszkodzonym Lan-em. Komputerek działa, grzeje się chip i malina pobiera więcej prądu. Leży gdzieś na dnie pudełka i raczej z niej nie skorzystam, a podmieniać układu nie zamierzam.

To byłby dawca oryginalnego układu zasilania, o ile da się go tak po prostu przelutować. 

Oryginalnie płyta jest wykonana w technologii bezołowiowej, która wymaga wyższych temperatur lutowania. Do tego ten układ posiada radiator pod całym spodem, więc trzeba grzać płytę oraz cały układ i to dość długo. Przy wylutowaniu z musiałem użyć hot air na 340°C bo niżej nie chciał pływać. Jestem przekonany, że podgrzanie do tej temperatury zniszczyło struktury wewnętrzne. Nie wiem czy dodatkowo nie był jakoś klejony do płyty, bo na prawdę stawiał duży opór przed usunięciem.

Czyli wątpię czy po wyjęciu oryginału od dawcy miałby on szansę poprawnie zapracować u biorcy.

Nie sądzę żeby ktokolwiek z odrobiną wiedzy na ten temat podjął się takiej operacji. 99% to porażka na dzień dobry

Czekam jeszcze na ostateczny wynik drugiego podejścia do naprawy. Między czasie dzięki @steel_rat udało mi się uwolnić od GPIO w Rpi. Więc ewentualna droga do przesiadki z Rpi na terminal już się skróciła. Nie wiem tylko jak ja go zmieszczę w szafce 😉

@Isom na takim HP T620 smarticz odpala ?

@daro1003 Nie , smarticz to inny system operacyjny 

@daro1003 SMARTICZ jest oparty na Raspian`ie a to inna architektura procesora - arm, to co pytasz to zwykły x86.

Więc jak można wykorzystać taki HP T620 w instalacji ? Czy np może obsługiwać ekran dotykowy jaki zbudował @adrian zamiast RBPI ? Jest na nim windows więc może zwiększy funkcjonalność ekranu dobrze kombinuje ?

@daro1003 nie wiem czy zwiększy funkcjonalność, niby jak? Będzie działać podobnie. Jeśli masz tam Windows`a to musisz dodać sterowniki do dotyku. Obraz - w zależności od ekranu, z tego co widzę T620 ma wy display port, a ekran najczęściej HDMI.

Możesz zainstalować na nim Debian`a, a resztę podobnie jak na Smarticz`u.

Ok dzięki za wyjaśnienie.

@daro1003 kilka postów wyżej wyjaśniam co trzeba zrobić z takim terminalem , nie zostawiam tam windy tylko instaluję Ubuntu czyli linux , podłączenie ekranu wygląda identycznie jak w raspberry tylko potrzebna przejściówka z display port na hdmi i uruchomienie trybu kiosk.

Jak masz działający system na Pi 4 to zostaw w spokoju , taki HP to alternatywa dla  tych co chcą zacząć i nie wydawać kroci na nową malinę.