Witam wszystkich,
Mam uporczywy problem podczas próby wgrania OpenBeken do inteligentnego wyłącznika przedpłatowego Tuya wyposażonego w układ BK7238 (T1). Spędziłem nad tym wiele godzin i wypróbowałem niemal wszystkie dostępne metody diagnostyczne, ale całkowicie utknąłem. Byłbym bardzo wdzięczny za wszelkie wskazówki od ekspertów obecnych na tym forum.
Poniżej znajduje się szczegółowy opis mojego sprzętu, przebiegu problemu oraz wszystkich kroków, które wykonałem do tej pory.
1. Sprzęt i konfiguracja
Urządzenie docelowe: Inteligentny wyłącznik przedpłatowy Tuya (oparty na TuyaMCU, prędkość transmisji 9600 baud).
Moduł Wi-Fi: BK7238 (wewnętrzna platforma T1).
Zasilanie: Zewnętrzny laboratoryjny zasilacz ustawiony na stabilne 3,3 V (zdolny do dostarczenia wysokiego prądu), monitorowany za pomocą amperomierza.
Adapter UART: Początkowo FT232RL (który później nie przeszedł testu loopback), obecnie używam Arduino Uno jako przejściówki USB-TTL w trybie pass-through (pin RESET podłączony do GND).
Połączenia: Wspólna masa (GND) jest w 100% prawidłowo połączona pomiędzy zasilaczem laboratoryjnym, układem oraz adapterem UART.
2. Oś czasu (jak rozpoczął się problem)
Faza 1 (Pełny sukces):
Pomyślnie połączyłem się z układem i odczytałem oryginalne oprogramowanie przy użyciu narzędzia BK7231 GUI Flash Tool. Kopia zapasowa została utworzona poprawnie, a narzędzie bez problemu odczytało konfigurację Tuya (Platforma: T1, Baud: 9600, obecność TuyaMCU została potwierdzona).
Faza 2 (Awaria):
Kliknąłem przycisk flashowania, aby wgrać firmware OpenBeken. Proces rozpoczął się, ale zakończył się błędem dokładnie podczas pierwszego etapu kasowania pamięci z następującym komunikatem:
Faza 3 (Stan obecny):
Od momentu wystąpienia tego błędu podczas kasowania pamięci układ wydaje się znajdować w stanie częściowego uszkodzenia programowego („soft brick”). Za każdym razem, gdy próbuję ponownie go zaprogramować, otrzymuję niekończącą się pętlę błędów:
3. Kroki diagnostyczne, które zostały już wykonane (ponad 100 prób!)
Aby zaoszczędzić Wasz czas, poniżej przedstawiam wszystkie testy, które już przeprowadziłem:
Synchronizacja cyklu zasilania:
Pozostawiłem przewód 3,3 V odłączony, kliknąłem przycisk „Flash” w GUI, a dokładnie w momencie pojawienia się komunikatu:
podłączyłem przewód 3,3 V, aby uzyskać ostre zbocze narastające zasilania. Nie było żadnej reakcji.
Resetowanie pinu CEN:
Pozostawiłem zasilanie włączone, uruchomiłem proces flashowania i na około 0,5 sekundy zwarłem pin CEN do GND podczas pętli „Getting bus”. Próbowałem również metody „Woodpecker” (szybkie, wielokrotne zwarcia pinu do GND). Bez rezultatu.
Diagnostyka amperomierzem:
Układ pobiera normalny prąd w zakresie od 30 mA do 80 mA podczas pracy, co wskazuje, że nie został fizycznie uszkodzony. Gdy zwieram pin CEN do GND, pobór prądu spada do około 0 mA, co potwierdza prawidłowe działanie wewnętrznego obwodu resetu.
Prędkości transmisji:
Próbowałem zmienić prędkość programatora na 115200 baud, a następnie ponownie ustawić 921600 baud.
Zmiana adaptera UART:
Po niepowodzeniu testu loopback mojego adaptera FTDI przeszedłem na użycie Arduino Uno (RESET połączony z GND) jako mostka szeregowego. (Uwaga: w tej konfiguracji połączyłem TX z TX oraz RX z RX zgodnie z wymaganiami dla tego obejścia).
Hard Recovery:
Czy istnieje jakaś specyficzna metoda „hard recovery” lub alternatywne narzędzie (takie jak hid_download_py lub Beken Writer 1.60) dla układu BK7238, który uległ awarii dokładnie podczas operacji:
Posiadam bezpiecznie zachowaną kopię zapasową oryginalnego firmware'u, ale muszę jedynie ponownie uzyskać odpowiedź magistrali komunikacyjnej.
Z góry dziękuję za poświęcony czas oraz wszelką pomoc i wiedzę ekspercką!
Mam uporczywy problem podczas próby wgrania OpenBeken do inteligentnego wyłącznika przedpłatowego Tuya wyposażonego w układ BK7238 (T1). Spędziłem nad tym wiele godzin i wypróbowałem niemal wszystkie dostępne metody diagnostyczne, ale całkowicie utknąłem. Byłbym bardzo wdzięczny za wszelkie wskazówki od ekspertów obecnych na tym forum.
Poniżej znajduje się szczegółowy opis mojego sprzętu, przebiegu problemu oraz wszystkich kroków, które wykonałem do tej pory.
1. Sprzęt i konfiguracja
Urządzenie docelowe: Inteligentny wyłącznik przedpłatowy Tuya (oparty na TuyaMCU, prędkość transmisji 9600 baud).
Moduł Wi-Fi: BK7238 (wewnętrzna platforma T1).
Zasilanie: Zewnętrzny laboratoryjny zasilacz ustawiony na stabilne 3,3 V (zdolny do dostarczenia wysokiego prądu), monitorowany za pomocą amperomierza.
Adapter UART: Początkowo FT232RL (który później nie przeszedł testu loopback), obecnie używam Arduino Uno jako przejściówki USB-TTL w trybie pass-through (pin RESET podłączony do GND).
Połączenia: Wspólna masa (GND) jest w 100% prawidłowo połączona pomiędzy zasilaczem laboratoryjnym, układem oraz adapterem UART.
2. Oś czasu (jak rozpoczął się problem)
Faza 1 (Pełny sukces):
Pomyślnie połączyłem się z układem i odczytałem oryginalne oprogramowanie przy użyciu narzędzia BK7231 GUI Flash Tool. Kopia zapasowa została utworzona poprawnie, a narzędzie bez problemu odczytało konfigurację Tuya (Platforma: T1, Baud: 9600, obecność TuyaMCU została potwierdzona).
Faza 2 (Awaria):
Kliknąłem przycisk flashowania, aby wgrać firmware OpenBeken. Proces rozpoczął się, ale zakończył się błędem dokładnie podczas pierwszego etapu kasowania pamięci z następującym komunikatem:
failed, will retry! Erasing block 0x00...failed with serial.BytesToRead 0 (expected 16)
Faza 3 (Stan obecny):
Od momentu wystąpienia tego błędu podczas kasowania pamięci układ wydaje się znajdować w stanie częściowego uszkodzenia programowego („soft brick”). Za każdym razem, gdy próbuję ponownie go zaprogramować, otrzymuję niekończącą się pętlę błędów:
Getting bus failed, will try again - 0/100!
...
Getting bus failed, will try again - 99/100!
Failed to get bus!
3. Kroki diagnostyczne, które zostały już wykonane (ponad 100 prób!)
Aby zaoszczędzić Wasz czas, poniżej przedstawiam wszystkie testy, które już przeprowadziłem:
Synchronizacja cyklu zasilania:
Pozostawiłem przewód 3,3 V odłączony, kliknąłem przycisk „Flash” w GUI, a dokładnie w momencie pojawienia się komunikatu:
Getting bus... 0/100
podłączyłem przewód 3,3 V, aby uzyskać ostre zbocze narastające zasilania. Nie było żadnej reakcji.
Resetowanie pinu CEN:
Pozostawiłem zasilanie włączone, uruchomiłem proces flashowania i na około 0,5 sekundy zwarłem pin CEN do GND podczas pętli „Getting bus”. Próbowałem również metody „Woodpecker” (szybkie, wielokrotne zwarcia pinu do GND). Bez rezultatu.
Diagnostyka amperomierzem:
Układ pobiera normalny prąd w zakresie od 30 mA do 80 mA podczas pracy, co wskazuje, że nie został fizycznie uszkodzony. Gdy zwieram pin CEN do GND, pobór prądu spada do około 0 mA, co potwierdza prawidłowe działanie wewnętrznego obwodu resetu.
Prędkości transmisji:
Próbowałem zmienić prędkość programatora na 115200 baud, a następnie ponownie ustawić 921600 baud.
Zmiana adaptera UART:
Po niepowodzeniu testu loopback mojego adaptera FTDI przeszedłem na użycie Arduino Uno (RESET połączony z GND) jako mostka szeregowego. (Uwaga: w tej konfiguracji połączyłem TX z TX oraz RX z RX zgodnie z wymaganiami dla tego obejścia).
Hard Recovery:
Czy istnieje jakaś specyficzna metoda „hard recovery” lub alternatywne narzędzie (takie jak hid_download_py lub Beken Writer 1.60) dla układu BK7238, który uległ awarii dokładnie podczas operacji:
Erasing block 0x00
Posiadam bezpiecznie zachowaną kopię zapasową oryginalnego firmware'u, ale muszę jedynie ponownie uzyskać odpowiedź magistrali komunikacyjnej.
Z góry dziękuję za poświęcony czas oraz wszelką pomoc i wiedzę ekspercką!
