ESP32-C2 Boot Loop po flashowaniu OpenESP32C2_1.18.158_2M na module WiFi 2MB

Witam,

Próbuję przeflashować moduł WiFi kontrolera ładowania słonecznego z oprogramowaniem open source.
.

Raporty Esptool:

Flashowanie modułu za pomocą:
udaje się, ale potem urządzenie (wciąż zasilane tylko z mojej przejściówki USB-serial) nie uruchamia się, tylko spontanicznie restartuje, np:
Myślę, że nie uruchamia się również przy zasilaniu z akumulatora samochodowego, ponieważ nie pojawia się jego AP.

Próbowałem też tasmota i esphome, z podobnym skutkiem. Po przywróceniu oryginalnego oprogramowania urządzenie działa poprawnie.

Jakieś pomysły co robię źle?
AI: Czy mógłbyś podać dokładną markę i model modułu WiFi oraz kontrolera ładowania słonecznego, z którego pochodzi? Pomoże to ustalić, czy istnieją jakiekolwiek znane problemy z kompatybilnością lub specjalne wymagania dotyczące sprzętu.

https://aliexpress.com/item/1005008843512568.html
AI: Skąd pobrałeś OpenESP32C2_1.18.158_2M.factory.bin (i obrazy Tasmota/ESPHome), które flashowałeś - czy zostały pobrane wstępnie zbudowane, czy sam je zbudowałeś? Jeśli zbudowałeś, jaką płytę lub konfigurację wybrałeś?
https://github.com/openshwprojects/OpenBK7231.../1.18.158/OpenESP32C2_1.18.158_2M.factory.bin

Obrazy Tasmota oznaczone ESP32C2 dostępne na https://tasmota.github.io/install/

Niestandardowy obraz ESPHome wygenerowany z następującą konfiguracją (wifi i sekcje zależne włączone lub wyłączone):

Czy możesz dostarczyć oryginalną kopię zapasową oprogramowania?

@divadiow @insmod pomysły? Nie jestem pewien, czy mam C2 pod ręką, ale jestem pewien, że testowałem OpenESP32 na S3 zaledwie kilka dni temu i działało dobrze.

C2 był w porządku zaledwie tydzień lub dwa temu https://www.elektroda.com/rtvforum/topic4134135.html

Wydaje mi się, że nie mam C2 dev board. Mogę jednak przetestować C3 / C6

Dodano po 6 [minutach]:

OK, więc to nie C2, ale 4mb C3 bootuje OBK OK flashowany jako:

Użytkownik twierdzi, że próbował również Tasmota itp., więc możliwe, że coś jest nie tak niż nasze binarne.

<usunięte> nieistotne

>>21643289
Tak zrobię, jak tylko przechwycę kolejną kopię z wyczyszczonymi ustawieniami lokalnymi po reflashingu.

Dodano po 52 [minutach]: .

Niestety mój jedyny adapter USB-serial (FTD) nagle przestał działać - nie pojawia się już w systemie po podłączeniu. Ponieważ kilka razy udało mi się z powodzeniem przeflashować oryginalny firmware na problematycznym module za pomocą tego adaptera, nie sądzę, aby mógł on być odpowiedzialny za moje problemy z twoim i innymi firmware, ale tak czy inaczej, wygląda na to, że muszę kupić nowy, zanim będę mógł kontynuować.

Częstotliwość kryształu 40 MHz - wymaga specjalnych flag w czasie kompilacji
CONFIG_XTAL_FREQ_40=y
CONFIG_XTAL_FREQ=40

Dodano po 1 [godzinie] 34 [minutach]:

Dla niższego rozmiaru binarnego w esphome

Ale widzę, że masz tylko UART podłączony do modułu.
Więc prawdopodobnie istnieje jakiś niestandardowy protokół UART - trzeba by go ręcznie sniffować za pomocą oryginalnego oprogramowania układowego.

insmod napisał:

Ale widzę, że na module masz wyprowadzony tylko UART.
Więc prawdopodobnie jest jakiś niestandardowy protokół UART - trzeba by go ręcznie sniffować z oryginalnym firmware.

Tak, tylko UART. Moim planem jest sprawdzenie, czy protokół Modbus jest używany.

Mogę pomóc w inżynierii wstecznej i napisaniu sterownika do tego w OBK. Zacznij od przechwytywania pakietów.

OK, otrzymałem nowy adapter USB-serial, więc mogę kontynuować moje próby.

Najpierw wypróbowałem proponowane poprawki konfiguracji ESPHome, ale to nie pomogło. Wygląda na to, że bootloader drugiego etapu nie zadziałał. Zastanawiam się, czy może coś jest nie tak z układem partycji.

Następnie pomyślnie przeflashowałem urządzenie oryginalnym oprogramowaniem układowym. Oto log bootowania: Ostatnie trzy linie powtarzają się w sposób ciągły. Wygląda mi to na komunikaty Modbus.

Nie ma odpowiedzi z ładowarki słonecznej, ponieważ tylko moduł WiFi jest zasilany z regulatora adaptera USB-seryjnego. Nie nawiązano również połączenia WiFi, prawdopodobnie z powodu braku odpowiedzi. Jutro zamierzam podłączyć urządzenie do akumulatora samochodowego i spróbować przechwycić odpowiedzi Modbus z ładowarki, mam nadzieję, że zostaną zgłoszone do konsoli szeregowej. Następnie wyczyszczę poświadczenia WiFi i zrzucę firmware do udostępnienia.

Dobrze znam modbus i planowałem dodać go do OBK, to może być dobry moment, aby to zrobić.
przydatne narzędzie: https://npulse.net/en/online-modbus

Załączam dziennik konsoli szeregowej przefiltrowany z naciskiem na wymianę danych Modbus z kontrolerem ładowania słonecznego przez UART.

W skrócie, dwa zestawy rejestrów są odpytywane o ich zawartość co 10 sekund:
Od czasu do czasu inny pojedynczy rejestr jest zapisywany z wartością 0 lub 1, np:
.
Nie udało mi się wyczyścić wszystkich kopii poświadczeń WiFi przechowywanych w pamięci flash modułu WiFi (jest ich kilka). Mogę binarnie edytować zrzut oprogramowania układowego, ale wtedy nie jestem pewien, czy nadal będzie się uruchamiać z powodu potencjalnie nieprawidłowych sum kontrolnych. Czy obraz przygotowany w ten sposób będzie nadal przydatny?

Myślę, że znalazłem sposób na wyczyszczenie moich danych uwierzytelniających: nadpisanie ich fałszywymi danymi. Jak dotąd częściowy sukces, ale będę kontynuował.

Hmmm, widzę, że sytuacja się zmieniła. Jesteśmy teraz pewni, że obsługa modbus jest potrzebna. Myślę, że nie potrzebuję kopii firmware urządzenia. Mogę przygotować obsługę modbus w OBK. Czy możesz zrobić listę rejestrów modbus dla tego konkretnego urządzenia i jak są one używane? Może również pełne przechwycenie komunikacji (jeśli nie ma tego w poprzednim poście?)?

Wiesz, mogę uruchomić OBK w systemie Windows - z symulatorem OBK - więc mogę łatwo opracować dla niego sterownik modbus, zwłaszcza z przechwytywaniem pakietów.

ESP32 jest tutaj masterem modbus, prawda?

Tak, ESP32 jest urządzeniem nadrzędnym modbus.

Jak informowałem, odpytywane są dwa zakresy rejestrów przechowujących. Oto, co aplikacja modbus z podanego linku mówi nam o tych zapytaniach.

Pierwsze zapytanie o zakres: Przykładowa odpowiedź:
2. zapytanie o zakres: Przykładowa odpowiedź:
Aby znaleźć korelacje między tymi rejestrami a wartościami fizycznymi mierzonymi lub kontrolowanymi przez ładowarkę słoneczną, pomocny byłby sposób obserwowania wartości raportowanych przez modbus, wygodniejszy niż obserwowanie dziennika konsoli. Może można by rozszerzyć aplikację internetową o pola dostarczające wartości odczytywane z rejestrów modbus pod adresami określonymi przez użytkownika?

Poza tym wciąż nie jestem w stanie uruchomić OBK (ani żadnego innego firmware'u niż fabryczny) na module, więc na razie nie mam możliwości przetestowania twojej pracy.

W końcu udało mi się rozwiązać problem braku możliwości wyczyszczenia danych uwierzytelniających WiFi z pamięci flash z fabrycznym oprogramowaniem układowym. Skasowałem region flash, który zawierał wiele kopii tych danych uwierzytelniających za pomocą esptool. Po włączeniu zasilania moduł uruchomił się poprawnie, bez połączenia WiFi. Następnie zrzuciłem zawartość pamięci flash, tym razem bez danych uwierzytelniających WiFi.
Kopia znajduje się w załączniku.

Wydaje się, że operacja kasowania regionu pamięci flash nie ma wpływu na komunikację Modbus.

Brak postępów w uruchamianiu modułu z OBK lub innym oprogramowaniem open source.

fajnie. buty dla mnie na 26Mhz C2

Oprócz częstotliwości Crystal: 40MHz vs 26MHz, o której wspomniałeś, mogę zobaczyć następujące inne różnice sprzętowe, porównując dzienniki rozruchu fabrycznego oprogramowania układowego:
- wersja chipa: v1.2 vs v1.0
- Prędkość SPI: 30MHz vs 60MHz
- Rozmiar pamięci flash SPI: 2MB vs. 4MB

Widzę również SPI Speed: 60MHz zgłaszane przez ESP-IDF v5.5 2nd stage bootloader podczas uruchamiania OBK na moim urządzeniu (vs 30MHz zgłaszane przez v5.0.1 z fabrycznym oprogramowaniem układowym).

Jeszcze jedna różnica sprzętowa:
- wykryty chipset: generic vs gd

Wydaje mi się, że zidentyfikowałem kilka rejestrów. Zakres zaczynający się od przesunięcia rejestru 0x1 wydaje się dostarczać wartości na żywo, podczas gdy drugi, zaczynający się od przesunięcia rejestru 0x1001, jest miejscem przechowywania ustawień.

Wartości na żywo przy przesunięciu 0x1:

Ustawienia przy offsecie 0x1001:

Witam,
Udało mi się uruchomić ESPHome na moim module ESP32-C2 z fabrycznie zainstalowanym bootloaderem 2nd stage. Zainstalowałem mój obraz ESPHome .ota.bin za pomocą esptool pod adresem flash 0x10000. W moim obrazie ESPHome .factory.bin brakowało tylko kodu bootloadera drugiego etapu, zastąpionego wszystkimi jedynkami (0xff). Jest to problem z obsługą ESP32-C2 w aktualnym ESPHome, jak sądzę (próbowałem 2025.8.1 i 2025.8.2). W takim razie na razie nie jestem w stanie używać OTA do aktualizacji oprogramowania układowego, ale w każdym razie mogę kontynuować eksplorację urządzenia. BTW, dziękuję @insmod za podzielenie się wskazówkami dotyczącymi konfiguracji ESPHome, okazały się one bardzo pomocne. Oto dziennik rozruchu.

EDIT:
OTA jest możliwe, aby zadziałało należy zlokalizować plik partitions.bin dla urządzenia w drzewie plików uruchomieniowych esphome i wgrać go do pamięci flash przez port szeregowy za pomocą esptool z offsetem 0x8000.

Próbowałem również podobnej sztuczki z OBK .img, ale to nie zadziałało. Jednak dziennik rozruchu wyglądał inaczej niż po zainstalowaniu OBK .factory.bin, może to rzuci więcej światła na przyczynę niepowodzenia rozruchu. Oto kopia:

Dla kompletności zapisu, próbowałem również uruchomić ESPHome z OBK 2nd stage bootloader, i to też nie działa.

Konfiguracja ESPHome dla Modbus UART:
.
Poza tym są dwie diody LED, raczej niewidoczne z zewnątrz obudowy urządzenia.

Cześć @p.kaczmarek2, chociaż już skonfigurowałem moje urządzenie z ESPHome i podłączyłem je do mojej konfiguracji HA, gdzie teraz monitoruję moją ładowarkę słoneczną, nadal jestem skłonny przetestować rozwiązanie oparte na OBK, gdy tylko obsługa Modbus będzie gotowa do testowania, a OBK będzie mógł uruchomić się na moim urządzeniu.

Wygląda na to, że problem braku możliwości uruchomienia OpenESP32C2 nie ogranicza się do mojego kontrolera ładowania słonecznego.

Kupiłem kilka modułów ESP8684-WROOM-03 (lub klonów?) na AliExpress.

Sflashowałem OpenESP32C2_1.18.208_2M.factory.bin na jednym z nich. Uruchamianie nie kończy się, ale zapętla się, jak pokazano poniżej.

Próbowałem zrzucić zawartość pamięci flash modułu przed ponownym flashowaniem i okazało się, że jest pusta, z wyjątkiem następującego fragmentu:

Uruchomienie modułu ESP8684-WROOM-03 z fabrycznym oprogramowaniem mojego kontrolera ładowania słonecznego wydaje się udane - moduł wchodzi w pętlę odpytywania serwera modbus przez UART.

Jednak sztuczka z flashowaniem obrazu ESPHome OTA przy 0x1000 na tym fabrycznym oprogramowaniu układowym, która działała dla tego kontrolera ładowania słonecznego, nie działa dla mnie z modułem ESP8684-WROOM-03.

Jakieś pomysły?

>>21748392
Za mało mocy

>>21748778
Przepraszam za brak odpowiedzi. Poinformuję o wynikach, gdy tylko zainstaluję moduł w prawdziwym urządzeniu.