[UWAGA] Koniec wsparcia dla FLASH 4MB [bramka ZigBee]

[vajera]

Tytuł oczywiście clickbait-owy, ale zależy mi na przyciągnięciu uwagi wszystkich zainteresowanych.

W końcu nadszedł ten moment - wielkość kodu bramki, również w wersji bez logów, przekroczyła maksymalny rozmiar partycji ustalony przeze mnie w styczniu 2025 - oczywiście mowa tylko i wyłącznie o modelach C6 z 4 MB FLASH.

Nie oznacza to oczywiście, że kolejne wersje oprogramowania bramki nie będą mogły działać np. na Xiao C6, ale konieczna jest reorganizacja partycji.
Zabiorę kilkaset kB z partycji plików i dołożę je do partycji aplikacji - poniżej kilka informacji:

1. W przypadku budowania nowej bramki na urządzeniu z 4 MB FLASH wystarczajace będzie wgranie pliku full version (wersja 1.5.0) i wtedy kolejne aktualizacje nie będą wymagać żadnych zmian.
2. W przypadku potrzeby przeniesienia istniejącej bramki konieczne będzie wykonanie kopii zapasowej i odtworzenie jej po wgraniu full version 1.5.0. Ta kopia zapasowa będzie nieco bardziej skomplikowana, bo wymaga ręcznego przeniesienia plików bramki, ale są do tego wygodne narzędzia. Przygotuję odpowiedni poradnik, liczę też na pomoc ze strony forumowych weteranów

[Robinson74]

Przygotuję odpowiedni poradnik, liczę też na pomoc ze strony forumowych weteranów

Może znaczną część tego poradnika udałoby się metodą kopiuj-wklej wykorzystać do zrobienia także poradnika backupów bramek ESP32-C6, ale dla 8-16 MB.

[vajera]

Przygotuję odpowiedni poradnik, liczę też na pomoc ze strony forumowych weteranów

Może znaczną część tego poradnika udałoby się metodą kopiuj-wklej wykorzystać do zrobienia także poradnika backupów bramek ESP32-C6, ale dla 8-16 MB.

Na dzisiaj bramka nie wykorzystuje dodatkowych 8MB FLASH, więc robisz kopię całego 8MB (od adresu 0x0000, size 0x800000) i wgrywasz ją do modułu 16 MB od adresu 0x0000.

[zzrr]

@vajera jak już zdecydujesz jak będzie wyglądał nowy podział partycji to wstaw tutaj może .csv. Będzie można przygotować jakiś gotowy algorytm postępowania dla osób które będą musiały migrować dane na nowy system. Będą potrzebne dane typu offset partycji czy jej dokładana nowa wielkość.

[vajera]

@vajera jak już zdecydujesz jak będzie wyglądał nowy podział partycji to wstaw tutaj może .csv. Będzie można przygotować jakiś gotowy algorytm postępowania dla osób które będą musiały migrować dane na nowy system. Będą potrzebne dane typu offset partycji czy jej dokładana nowa wielkość.

Wszystko jest od zawsze na GitGub W katalogu partitions masz ten plik CSV - jedyna zmiana to wyrównanie rozmiaru partycji aplikacji do tego samego, co w przypadku 8MB (0x340000 bajtów) i odpowiednie zmniejszenie partycji spiffs.

Jest już również dostępny release 1.5.0, gdzie wersja 4MB ma już nowy układ partycji, stopniowo będę tutaj wrzucać wskazówki migracji.

[zzrr]

@vajera jak już zdecydujesz jak będzie wyglądał nowy podział partycji to wstaw tutaj może .csv. Będzie można przygotować jakiś gotowy algorytm postępowania dla osób które będą musiały migrować dane na nowy system. Będą potrzebne dane typu offset partycji czy jej dokładana nowa wielkość.

Wszystko jest od zawsze na GitGub W katalogu partitions masz ten plik CSV - jedyna zmiana to wyrównanie rozmiaru partycji aplikacji do tego samego, co w przypadku 8MB (0x340000 bajtów) i odpowiednie zmniejszenie partycji spiffs.

Jest już również dostępny release 1.5.0, gdzie wersja 4MB ma już nowy układ partycji, stopniowo będę tutaj wrzucać wskazówki migracji.

Ok. Dzięki. Ja @vajera wiem że ten plik partycji dla 4Mb jest tam gdzie napisałeś od zawsze. Mi chodziło o konkretny nowy po zmianie. Jednak faktycznie tak jak piszesz będzie on przecież w źródłach 1.5.0. jako ten custom już zmieniony. Tak?
EDIT:

Jest już również dostępny release 1.5.0, gdzie wersja 4MB ma już nowy układ partycji, stopniowo będę tutaj wrzucać wskazówki migracji.

W sumie to chyba to jest odpowiedź więc wszystko jasne.

[vajera]

Mój poradnik chciałbym oprzeć na narzędziu online - nie jest to najszybsze rozwiązanie, ale wydaje się najbezpieczniejsze i najbardziej oporne na błędy.

https://thelastoutpostworkshop.github.io/ESPConnect/

Część I - Kopia zapasowa.

1. Podłączamy bramkę do portu USB, otwieramy powyższy link i korzystając z przycisku CONNECT łączymy się z bramką.

2. Wchodzimy najpierw w sekcję Flash Tools i klikamy przycisk DOWNLOAD ALL PARTITIONS.

UWAGA - czasami w trakcie pobierania partycji występuje błąd - należy się upewnić, że rzeczywiście pobrane zostały wszystkie partycje (10 plików *.bin). Jeżeli błąd pobierania będzie się powtarzał, to należy ręcznie (DOWNLOAD SELECTED PARTITION) pobrać następujące partycje: nvs, spiffs, zb_storage, zb_fct, rcp_fw.


3. Następnie wchodzimy w sekcję LittleFS Tools - tam musimy pobrać ręcznie wszystkie pliki bramki:

- trzy pliki z katalogu głównego,
- wszystkie pliki z katalogu supla - należy je zapisać w oddzielnym katalogu (najlepiej o nazwie supla),
- wszystkie pliki z katalogu z2s_gateway - również należy je zapisać w oddzielnym katalogu,
- katalog zigbee_ota można pominąć.

W tym momencie mamy już wszystkie niezbędne elementy potrzebne do odtworzenia bramki w nowym układzie partycji.


Część II - Instalacja nowej wersji.

1. Opcjonalnie czyścimy pamięć FLASH docelowej bramki (procedura zalecana).

2. Wgrywamy plik full_version (począwszy od wersji 1.5.0 wzwyż) - znowu dostępna jest wersja z logami i bez nich.


Część III - Odtworzenie kopii zapasowej.

1. Podłączamy bramkę do portu USB, otwieramy powyższy link i korzystając z przycisku CONNECT łączymy się z bramką.

2. Wchodzimy najpierw w sekcję Flash Tools i przechodzimy do panelu Flash Firmware:

A) w okienku firmware binary wybieramy uprzednio zapisany plik nvs_0x900.bin, z listy Recommended offsets nvs - w polu Flash offset powinna wskoczyć wartość 0x9000 - naciskamy FLASH FIRMWARE,
B) te same czynności (A) powtarzamy dla pliku zb_storage.bin, offset zb_storage, FLASH FIRMWARE,
C) te same czynności (A) powtarzamy dla pliku zb_fct.bin, offset zb_fct, FLASH FIRMWARE,
D) te same czynności (A) powtarzamy dla pliku rcp_fw.bin, offset rcp_fw, FLASH FIRMWARE.

UWAGA Wszystkie pozostałe pliki *.bin (6) ignorujemy - nie należy ich wgrywać do nowej bramki.

3. Przechodzimy do sekcji LittleFS Tools :

A) Edycja jest domyślnie zablokowana - trzeba nacisnąć przycisk BACKUP żeby odblokować SAVE TO FLASH.
B) Teraz należy ręcznie wgrać wszystkie pliki pobrane uprzednio z partycji LittleFS - z zachowaniem struktury katalogów.
C) Na koniec przechodzimy do głównego katalogu LittleFS i dopiero wtedy naciskamy SAVE TO FLASH.

UWAGA - To jest operacja jednorazowa - po jej wykonaniu będzie można wgrywać aktualizacje, tak jak do tej pory - plik upgrade_only pod adres 0x10000.

[LukiSpajder]

Pierwsza bramka na testy przeniesiona . Chociaż za pierwszym razem coś chyba namieszałem i nie wystartowała . Drugie podejście i poszło , chociaż ja zostawiłem bramkę matkę wrazie W a soft 1.5.0 wrzuciłem na nowe esp32c6 mini . I tam odtworzyłem pliki . Bramka wystartowała ale po chwili się rozłączała , problem był w konflikcie adresów IP jakie router przydzielał , musiła się już wcześnie rejestrować pod tym adresem a w tej chwili był zajęte . Ale reset rutera pomógł i wszystko gra . Urządzenia połączyły się bez problemu . To jeszcze mnie czekaj trzy takie operacje

[lukasz06]

Na szczęście dawno się pozbyłem bramek z 4MB

[vajera]

Pierwsza bramka na testy przeniesiona . Chociaż za pierwszym razem coś chyba namieszałem i nie wystartowała . Drugie podejście i poszło , chociaż ja zostawiłem bramkę matkę wrazie W a soft 1.5.0 wrzuciłem na nowe esp32c6 mini . I tam odtworzyłem pliki . Bramka wystartowała ale po chwili się rozłączała , problem był w konflikcie adresów IP jakie router przydzielał , musiła się już wcześnie rejestrować pod tym adresem a w tej chwili był zajęte . Ale reset rutera pomógł i wszystko gra . Urządzenia połączyły się bez problemu . To jeszcze mnie czekaj trzy takie operacje

Brawo Ty! Jesteś pierwszy, bo ja to tylko teoretycznie opisałem