Kupiłem lokalnie kilka tanich żarówek BNETA B22 RGBCCW i chciałem spróbować sflashować je za pomocą OpenBeken. Chciałem najpierw wypróbować tuya-cloudcutter, ale nie wiedziałem, czy zawierają one chipy Beken lub ESP (stare lub nowe zapasy itp.), Więc połączyłem je ze Smart Life, aby zobaczyć wersję oprogramowania układowego. Głupio zrobiłem aktualizację do oprogramowania układowego 1.0.0 (1.6.0) (MCU na 1.6.0), co, jak sądzę, naprawiło exploit, więc nie mogłem się z nimi połączyć przez cloudcutter.
Niestety, rozkręciłem go i znalazłem chip BK7231N przylutowany bezpośrednio do płytki. Od kilku godzin próbuję flashować przez UART, ale nie mogę wprowadzić układu do bootloadera. Sprawdziłem, czy układ odbiera dane szeregowe za pomocą oscyloskopu i tak jest, ale nie dostaję nic na RX, bez względu na to, ile razy wyłączałem / włączałem zasilanie lub podciągałem CEN do niskiego poziomu z różnymi czasami. RX jest utrzymywany w stanie wysokim (tak jak powinien), ale nie ma żadnych danych, poza początkową czkawką po CEN, która go włącza.
Próbowałem:
- Krótsze przewody, trzymanie przewodów od siebie itp. Sprawdziłem również przebieg na oscyloskopie, aby upewnić się, że jest czysty i wygląda dobrze?
- Sprawdziłem ciągłość wszystkich połączeń lutowanych
- Brak bezpośrednich połączeń na płytce prototypowej i w inny sposób
- Próbowałem zamienić TX / RX (oscyloskop pokazuje, która droga jest prawidłowa, ponieważ nie można kierować sygnału do portu o wysokim napięciu)
- Różne porty USB (na wypadek, gdyby sygnał TX był niewystarczający)
- Różne adaptery szeregowe TTL (obecnie używam CH340G, ale nawet próbowałem z homebrew ESP32 passthrough bezskutecznie)
- Sprawdziłem wszystkie inne pady, ponieważ są jeszcze dwa podłączone (prawdopodobnie) do pinów PWM, które komunikują się przez I2C z kontrolerem LED na drugiej płytce.
Konfiguracja:
- USB do płytki Geekcreit Arduino Uno (wersja 3.3V) z CH340G
- Atmel trzymany w resecie do obejścia i używający TX/RX do BK7231N przez cienki przewód 30AWG.
- 3.3V LDO zasila oba układy z wystarczającą mocą
- Użycie flashera Easy UART GUI
- Oscyloskop podłączony do TX/RX w celu debugowania
Czy jest jakaś wiedza na temat tego, że bootloader może zostać nadpisany najnowszym firmware, skutecznie wyłączając UART? Niestety nie mam dostępu do pinów SPI, ponieważ nie jest to moduł, więc nie mogę go flashować w ten sposób. Nie, chyba że będę naprawdę dobry w lutowaniu przewodów na QFN.
Każda inna pomoc również będzie mile widziana!
AI: Czy mógłbyś podać szczegółowy schemat połączeń lub przynajmniej dokładnie określić, które piny na BK7231N podłączyłeś do TX, RX, GND, CEN i innych istotnych linii podczas prób flashowania UART?
BK7231N ma pady dla U1_TX/U1_RX, które są podłączone do RX/TX na płytce szeregowej. GND jest współdzielony i podłączony do pada GND na płycie. Na płytce znajduje się pad 3.3V, który jest podłączony do LDO, który sprawdziłem ma 3.3V. Używam luźnego przewodu podłączonego do GND, aby podciągnąć CEN do niskiego poziomu.
AI: Czy próbowałeś manipulować jakimikolwiek pinami BOOT lub GPIO (oprócz CEN), aby zmusić chip do przejścia w tryb bootloadera, czy twoje podejście opierało się wyłącznie na przełączaniu CEN? Jeśli tak, to których pinów i jakiej sekwencji użyłeś?
Próbowałem innych pinów GPIO, ale tylko CEN zrobił coś zauważalnego. Dwa pozostałe piny GPIO są prawdopodobnie podłączone do PWM na pinach 24 i 26 (zgodnie z tradycją), a drugi jest oznaczony jako P21. Nie mogę nic uzyskać z tego pinu.
Dodano po 18 [minutach]: .
Dosłownie przed chwilą, gdy to napisałem, zobaczyłem, że poziomy napięcia TTL wynoszą 4 V, co jest zbyt wysokie dla układu BK. Przepuściłem go przez dzielnik napięcia, aby zbliżyć go do 3,3 V i zadziałało...
Niestety, rozkręciłem go i znalazłem chip BK7231N przylutowany bezpośrednio do płytki. Od kilku godzin próbuję flashować przez UART, ale nie mogę wprowadzić układu do bootloadera. Sprawdziłem, czy układ odbiera dane szeregowe za pomocą oscyloskopu i tak jest, ale nie dostaję nic na RX, bez względu na to, ile razy wyłączałem / włączałem zasilanie lub podciągałem CEN do niskiego poziomu z różnymi czasami. RX jest utrzymywany w stanie wysokim (tak jak powinien), ale nie ma żadnych danych, poza początkową czkawką po CEN, która go włącza.
Próbowałem:
- Krótsze przewody, trzymanie przewodów od siebie itp. Sprawdziłem również przebieg na oscyloskopie, aby upewnić się, że jest czysty i wygląda dobrze?
- Sprawdziłem ciągłość wszystkich połączeń lutowanych
- Brak bezpośrednich połączeń na płytce prototypowej i w inny sposób
- Próbowałem zamienić TX / RX (oscyloskop pokazuje, która droga jest prawidłowa, ponieważ nie można kierować sygnału do portu o wysokim napięciu)
- Różne porty USB (na wypadek, gdyby sygnał TX był niewystarczający)
- Różne adaptery szeregowe TTL (obecnie używam CH340G, ale nawet próbowałem z homebrew ESP32 passthrough bezskutecznie)
- Sprawdziłem wszystkie inne pady, ponieważ są jeszcze dwa podłączone (prawdopodobnie) do pinów PWM, które komunikują się przez I2C z kontrolerem LED na drugiej płytce.
Konfiguracja:
- USB do płytki Geekcreit Arduino Uno (wersja 3.3V) z CH340G
- Atmel trzymany w resecie do obejścia i używający TX/RX do BK7231N przez cienki przewód 30AWG.
- 3.3V LDO zasila oba układy z wystarczającą mocą
- Użycie flashera Easy UART GUI
- Oscyloskop podłączony do TX/RX w celu debugowania
Czy jest jakaś wiedza na temat tego, że bootloader może zostać nadpisany najnowszym firmware, skutecznie wyłączając UART? Niestety nie mam dostępu do pinów SPI, ponieważ nie jest to moduł, więc nie mogę go flashować w ten sposób. Nie, chyba że będę naprawdę dobry w lutowaniu przewodów na QFN.
Każda inna pomoc również będzie mile widziana!
AI: Czy mógłbyś podać szczegółowy schemat połączeń lub przynajmniej dokładnie określić, które piny na BK7231N podłączyłeś do TX, RX, GND, CEN i innych istotnych linii podczas prób flashowania UART?
BK7231N ma pady dla U1_TX/U1_RX, które są podłączone do RX/TX na płytce szeregowej. GND jest współdzielony i podłączony do pada GND na płycie. Na płytce znajduje się pad 3.3V, który jest podłączony do LDO, który sprawdziłem ma 3.3V. Używam luźnego przewodu podłączonego do GND, aby podciągnąć CEN do niskiego poziomu.
AI: Czy próbowałeś manipulować jakimikolwiek pinami BOOT lub GPIO (oprócz CEN), aby zmusić chip do przejścia w tryb bootloadera, czy twoje podejście opierało się wyłącznie na przełączaniu CEN? Jeśli tak, to których pinów i jakiej sekwencji użyłeś?
Próbowałem innych pinów GPIO, ale tylko CEN zrobił coś zauważalnego. Dwa pozostałe piny GPIO są prawdopodobnie podłączone do PWM na pinach 24 i 26 (zgodnie z tradycją), a drugi jest oznaczony jako P21. Nie mogę nic uzyskać z tego pinu.
Dodano po 18 [minutach]: .
Dosłownie przed chwilą, gdy to napisałem, zobaczyłem, że poziomy napięcia TTL wynoszą 4 V, co jest zbyt wysokie dla układu BK. Przepuściłem go przez dzielnik napięcia, aby zbliżyć go do 3,3 V i zadziałało...
