Witajcie, dziś krótka ciekawostka - mikrokontroler pracujący bez podłączenia jego pinów VDD. Praktyczna prezentacja oraz wyjaśnienie jak to jest możliwe. Sam mikrokontroler z tematu ruszył po samym podłączeniu mu masy oraz linii UART, czyli RX i TX. Okazało się być to w pełni wystarczające by uruchomić go w trybie bootloadera i nawet by odczytać jego pełny wsad flash, całe 2MB, bez żadnych błędów CRC. Jak to możliwe? Przekonajmy się!
Układ testowy
Pacjentem jest czujnik ruchu PIR z komunikacją WiFi, zrealizowany w oparciu o moduł WiFi CBU, czyli układ BK7231N, ale od razu zaznaczam, że opisywane tu zjawisko spotkacie też w normalnych, popularnych mikrokontrolerach. Z zewnątrz ktoś mógłby pomyśleć, że ten czujnik PIR ma po prostu wsadzone bateryjki, a całość to żart, ale na filmie widać, że slot na nie jest pusty.
Oto wspomniany filmik:
Na filmiku korzystam z mojego flashera BK7231 GUI Flash Tool:
https://github.com/openshwprojects/BK7231GUIFlashTool
Nie chcecie oglądać filmu? Nie ma problemu, oto sprawozdanie z akcji, krok po kroku:
1. Tutaj podłączony jest UART (w trybie 3.3V) oraz masa, VDD (normalnie 3.3V) wisi w powietrzu:
2. Na komputerze rozpoczynam procedurę programowania, a raczej oczekiwania na rozpoczęcie programowania
3. Tu zwieram do masy VDD od modułu WiFi, aby ten wykonał potem reboot, gdyż bootloader w tych układach tylko w momencie rebootu daje o sobie znać i czeka ułamek sekundy na handshake
4. VDD zostawiam w powietrzu, a mimo to trwa odczyt pamięci flash, czyli MCU pracuje:
5. Odczyt flash kończy się powodzeniem, nawet udaje się mojemu narzędziu (flasherowi) odczytać konfigurację GPIO Tuya:
6. Pokazuję dla formalności, że nie ma ukrytych bateryjek:
Wyjaśnienie zagadki
Raczej tutaj każdy jest już przekonany, że MCU ruszył na samym podłączeniu masy oraz RX i TX. Tylko dlaczego?
Odpowiedź umieszczam w spoilerze. Jeśli, czytelniku, chcesz, to sam się zastanów a potem dopiero sprawdź poniżej, czy miałeś rację.
Spoiler:
BK7231 jest dość egzotyczny, więc nie szukajmy nawet jego dokumentacji, tylko weźmy na stół coś bardziej popularnego.
Może by Atmega8? Atmegi chyba każdy zna, chociażby dzięki Arduino.
Co mówi nota katalogowa Atmegi na temat jej portów IO?
Wszystkie IO mają ochronne diody do VDD i GND, które niejako "ścinają" wyższe napięcia... te diody są w środku Atmegi, one nie są obok na płytce. Tylko co jeśli nie podłączymy zasilania? Wtedy jedna z tych diod, ta "ścinająca" do zasilania, może zacząć przewodzić...
Oczywiście ta dioda ma swój spadek napięcia, ale z reguły ten spadek nie jest na tyle duży, by napięcie pojawiająca się na VDD nie było wystarczające do wystartowania układu. Na wejściu jest 3.3V, spadek to, powiedzmy, 0.7V. 3.3-0.7 to 2.6, 2.6V jeszcze powinno starczyć by MCU ruszył.
Zostaje jeszcze jedna kwestia - czy sygnał UART, który siłą rzeczy raz jest w stanie niskim, a raz wysokim, jest w stanie utrzymać zasilanie na takim poziomie by BK7231 nie wykonał ani jednego rebootu w trakcie całej procedury zasilania?
Tutaj moim zdaniem ratują nas kondensatory na VDD. To one utrzymują MCU w stanie pracy nawet gdy chwilowo nie dostaje on zasilania przez GPIO.
Wiem jeszcze z doświadczenia, że te zjawisko nie występuje gdy moduł z BK7231 jest poza układem, tj. nie ma kondensatorów na VDD, jest wylutowany z płytki-matki.
Na koniec jeszcze jedna uwaga - te diody ochronne są w wielu układach, nie tylko w mikrokontrolerach:
Nie zawsze jest o nich mowa w notach katalogowach, ale wydaje mi się, że z reguły są one dostępne. Zresztą można to łatwo sprawdzić.
BK7231 jest dość egzotyczny, więc nie szukajmy nawet jego dokumentacji, tylko weźmy na stół coś bardziej popularnego.
Może by Atmega8? Atmegi chyba każdy zna, chociażby dzięki Arduino.
Co mówi nota katalogowa Atmegi na temat jej portów IO?
Wszystkie IO mają ochronne diody do VDD i GND, które niejako "ścinają" wyższe napięcia... te diody są w środku Atmegi, one nie są obok na płytce. Tylko co jeśli nie podłączymy zasilania? Wtedy jedna z tych diod, ta "ścinająca" do zasilania, może zacząć przewodzić...
Oczywiście ta dioda ma swój spadek napięcia, ale z reguły ten spadek nie jest na tyle duży, by napięcie pojawiająca się na VDD nie było wystarczające do wystartowania układu. Na wejściu jest 3.3V, spadek to, powiedzmy, 0.7V. 3.3-0.7 to 2.6, 2.6V jeszcze powinno starczyć by MCU ruszył.
Zostaje jeszcze jedna kwestia - czy sygnał UART, który siłą rzeczy raz jest w stanie niskim, a raz wysokim, jest w stanie utrzymać zasilanie na takim poziomie by BK7231 nie wykonał ani jednego rebootu w trakcie całej procedury zasilania?
Tutaj moim zdaniem ratują nas kondensatory na VDD. To one utrzymują MCU w stanie pracy nawet gdy chwilowo nie dostaje on zasilania przez GPIO.
Wiem jeszcze z doświadczenia, że te zjawisko nie występuje gdy moduł z BK7231 jest poza układem, tj. nie ma kondensatorów na VDD, jest wylutowany z płytki-matki.
Na koniec jeszcze jedna uwaga - te diody ochronne są w wielu układach, nie tylko w mikrokontrolerach:
Nie zawsze jest o nich mowa w notach katalogowach, ale wydaje mi się, że z reguły są one dostępne. Zresztą można to łatwo sprawdzić.
Podsumowanie
Taka sytuacja może co najmniej bardzo zaskoczyć początkujących, bo z zewnątrz może wydawać się bardzo nieintuicyjna, dopiero wiedza o budowie układu scalonego w środku w pełni wyjaśnia sprawę. Mnie to raczej nie zaskoczyło i z doświadczenia wiem, że w przypadku omawianych tu modułów WiFi sytuacja ma tylko miejsce gdy programowany BK7231 ma na VDD jakiś kondensator, jeśli wylutujemy go całkiem z układu to UART nie daje rady go utrzymać przy życiu.
Dajcie znać, czy spotkaliście się z tego typu zjawiskiem, które choć może wydawać się być problemem, jest jak najbardziej zrozumiałe - nie chciałbym, by GPIO moich MCU nie miały wbudowanej ochrony.
Na koniec dodam, że przedstawiona sytuacja z BK7231 może być wyjątkowo problematyczna i zaskakująca, bo ten MCU uruchamia bootloader tylko na chwilę po reboocie, więc ktoś może być bardzo zdziwiony, że wykonanie cyklu "podpięcie i odpięcie zasilania" nie uruchamia tego bootloadera. A wszystkiemu winne jest... wiadomo, zgodnie z opisem ze spoilera. Jedyne co pomaga tu wykonać reboot to chwilowe zwarcie VDD ze strony MCU do masy, choć też nie jest to zbyt dobry pomysł, bo de facto to zwiera sygnał UART przez wspomnianą diodę do masy...
Fajne? Ranking DIY Pomogłem? Kup mi kawę.
Czasami to pasożytnicze zasilanie powoduje, że układ działa ale nie do końca poprawnie. Np. przy normalnej pracy procek pobiera minimalny prąd, napięcie się utrzymuje ok i wszystko działa. Ale włączamy jakiś układ peryferyjny i wszystko siada, procek robi cuda, program ma dziwne błędy - help.
Bo dokładnie ten sam problem ponad 30 lat temu...
