ESP8266 z BLYNK często się resetuje. Co robić?

By: | Post date: Listopad 4, 2018

 

Nic. Podać adres i czekać.

A poważnie, jest to problem często spotykany w modułach zakupionych w znanym chińskim supermarkecie. Kosztujący dolara lub dwa moduł z ESP8266, który po miesiącu od zakupu trafia na nasze biurko jest napakowany jakąś odmianą chińskiego SDK. Albo czymś znacznie gorszym. Wgranie nowego softu za pomocą ARDUINO IDE teoretycznie powinno zadeptać wcześniejsze oprogramowanie. Teoretycznie. W wielu przypadkach resztki chińskiego softu jakoś wpływają na nasz program i zamiast działającego BLYNKa dostajemy resetujący się co jakiś czas elektroniczny bubel.

Dziś o tym jak poradzić sobie z takim problemem.

 

 

Jak wygląda problem? Najczęściej tak

 ets Jan  8 2013,rst cause:2, boot mode:(3,0)
Exception (0):
epc1=0x402044a4 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: sys
sp: 3ffffc30 end: 3fffffb0 offset: 01a0
ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v3de0c112

Co jakiś czas moduł staje dęba i resetuje się bez dania racji. Analiza przyczyn resetu zawarta w linii  ets Jan  8 2013,rst cause:2, boot mode:(3,0) nie ma sensu. Nic ciekawego nie da się z tego wyczytać. Tu np. sygnalizowany jest sprzętowy reset, którego w rzeczywistości nie ma. Mogą być inne komunikaty ale to nie ma większego znaczenia.

Jeśli nie zawieszamy programu w niekończącej się pętli powodującej zadziałanie procesorowego watchdoga w 95% przypadków przyczyna jest jedna – resztki chińskiego szmelcu zalegające pamięć flash mikrokontrolera dewastują nasz program. Jak to możliwe? Nie mam pojęcia. Ale wiem jak temu zaradzić.

Przez długi czas bylem przekonany, iż jedynym sposobem pozbycia się kłopotu jest wgranie nowego firmware. a szczególnie nowego bootloadera oskarżanego najczęściej o zakłócanie pracy naszej aplikacji. W moim przypadku nowy firmware przywracał prawidłowe działanie ESP z BLYNKiem w 100%

Ostatnio jednak odkryłem znacznie prostszy sposób pozbycia się nieproszonych gości. Trzeba po prostu wyczyścić całą pamięć flash. Wyczyścić tz. zapełnić ja samymi jedynkami 0xFF. I zadeptać oryginalny bootloader? Dokładnie tak.

Okazuje się, iż w ESP8266 ( a i w ESP32 także) bootloader jest na twardo zapisany w pamięci ROM procesora skąd w razie potrzeby jest w czasie startu przepisywany w odpowiednie miejsce. Dla całkowicie wyczyszczonej pamięci programu wgrywanie naszego kodu za pomocą ARDUINO IDE przebiega bez najmniejszych problemów. A najważniejsze, że pozbywamy się raz na zawsze nieoczekiwanych resetów naszego układu.

Procedura czyszczenia pamięci jest prosta. Za pomocą jakiejkolwiek wersji firmowego narzędzia ESPRESSIF Flash_Download_Tools wgrywamy plik złożony z samych jedynek od adresu ZERO 0x0000. I to wszystko.

Taki jedynkowy plik o długości zgodnej z wielkością pamięci flash naszego modułu pobieramy tu >>>>>

A tak ma wyglądać ustawienie konfiguracji programowania w programie Flash_Download_Tools. Plik do wgrania jest taki jak wielkość pamięci pokazywana przez program.

 

 

A więc śmiało katujmy nasz ulubiony ESP8266 bez obaw o uszkodzenie oryginalnego bootloadera (jak to czasami może się zdarzyć w modułach ARDUINO). Całkowite czyszczenie może mu tylko wyjść na zdrowie.

47

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Translate »