STM32 stop mode pobor pradu przed i po przerwaniu zewnetrznym

Witam
Moze zaczne od tego, ze problem rozwiazalem (nie wiem czy zgodnie ze sztuka ale dziala - o czym ponizej), jednak chcialbym sie zapytac dlaczego dzieje sie tak a nie inaczej.

Problem powstal od ESP8266 i jego deep sleep mode. Jak sie okazuje na rynku sa wadliwe ESP, ktore nie chca wstawac z tego trybu. Na 10 zamowiaonych z aliexpress - 5 wstawalo reszta nie. Zeby wyjsc z deep sleep mode w ESP8266 trzeba polaczyc GPIO16 z pinem restet. Po okreslonym, zadanym czasie pin GPIO16 generuje sygnal reset i w ten sposob ESP zaczyna swoj program od poczatku. W wadliwych ESP GPIO16 generuje sygnal resetu jednak nie jest on identyczny jak poprawnie dzialajacych IC. Z tego co widzialem w necie ludzie probowali resetowac wadliwy egzemplarz poprawnie dzialajacym, jednak bez skutku. Na poczatku myslalem, ze moze sygnal restetujacy jest za krotki i chcialem sprobowac uzyc zewnetrznego ic typu ic voltage supervisor z funkcja manualnego resetu. Jako ze w szufladzie walaja sie stm32f030 postanowilem zrobic szybki test i napisac program resetujacy ESP. Chyba dobrze, ze poszedlem ta droga, bowiem okazalo sie, ze to nie dlugosc sygnalu resetowego ma znaczenie a jego ilosc (tak, dopiero przy drugim sygnale resetujacym ESP powraca do zycia). Postanowilem juz zostac przy STM32f030 tylko, ze jako cala aplikacja jest zasilana bateryjnie, STM tez musial brac jak najmniej pradu. Caly system resetowania polega na tym, ze STM idzie spac (przechodzi w stop mode) i po otrzymaniu zbocza opadajacego z GPIO16 ESP wysyla dwa sygnaly resetujace poprzez mosfet (bss138) do ESP. Wszystko dziala jak powinno z jednym ale. Mianowicie po starcie STM gdzie po ustawieniu wszystkiego zgodnie z zaleceniami a w petli glownej mam tylko dwie linie :

pobor pradu waha sie w przedziale 1-4µA.
Natomiast po wybudzeniu i wykonaniu kodu z przerwania:

powracajac do trybu stop mode pobor pradu wzrasta do 40µA.
Problem rozwiazalem resetujac STM na koncu przerwania ;

wtedy znow pobor pradu jest w granicach 1-4µA.
Pytanie, dlaczego tak sie dzieje i gdzie jest moj blad?

Wracajac do ESP to prawdopodobnie chodzi o SDK w arduino (choc dziwne, ze jedne moduly dzialaja poprawnie a inne nie).
Przegladajac ten temat: https://github.com/esp8266/Arduino/issues/6007 natrafilem na kod:

i ten kod dziala. Moduly, ktore do tej pory nie wstawaly z deep sleep po zastapieniu procedury z arduino powyzszym kodem pracuja poprawnie.

Wciaz pozostje pytanie z pierwszego postu dotyczacego STM w stop mode.

khoam napisał:

Gdybyś doczytał do końca ten wątek, to odnalazłbyś informację:

a dalej stoi:

Cytat:

But how then to explain the problem of zombie mode on the ESP-01S modules without a programming mode switch , and powered by a laboratory power supply?
And how i have working deep sleep for half a year from Li-po through the WEMOS Battery Shield v 1.2 my WEMOS D1 Mini Pro ?
Maybe it makes sense to collect statistics on Flash chips in buggy modules (I think the thing is all the problem)
My two ESP-01S had FT25H08 and "zombie mode" problem, but after replase IC FLASH to Winbond it's work fine.

i dalej

Cytat:

Of course, it is impossible to explain everything, since there may be several reasons.
In the case of Autonomous power supply, the probability of this error is much less than with a USB connection.
The reason for this error may be a bad pulse on the Reset pin.
But I will repeat once again - this is an error in the hardware, not in the program and the reason for it is not correct pulse formation on the Reset pin and GPIO0pin.
I do not have such a problem, so I recommend that after writing the program, hardware install the GPIO pin in the program execution mode, and connect the rst pin to the GPIO16pin via a Schottky diode.
The ESP-01S does not have the GPIO16pin output that is needed for sleep mode.
So I can't guess why You have problems with ESP-01S.

wiec gosciu rowniez nie jest pewien.
Dzialajacy kod (chociaz nie analizowalem co on dokladnie wykonuje) wydaje sie przeczyc, ze jest to jednak blad hardware jako wszystko co jest dookola uc esp (przeciez i dzialajace i nie dzialajace moduly sa zbudowane identycznie). Bardziej sklanialbym sie do bledu w krzemie esp.
Sam zasilalem te moduly z roznych zrodel wliczajac zasilanie beteryjne. Co wiecej, na plytce wemos zamienialem niedzialajacy modul z dzialajacym i nie bylo problemu wiec sama pytka wemos nie stwarza problemu (moze zrobie test na samym module bez plytki wemos) i jezeli to jest blad hardware to samego modulu. Tylko zostaje wciaz pytanie dlaczego jedne moduly dzialaja a drugie nie, zachowujac dokladnie takie same warunki testowania.

Po przeprowadzonych testach moge stwierdzic, ze blad lezy po stronie hardwre samego modulu.
Test wygladal nastepujaco
Modul A - dzialajacy modul znajdujacy sie na plytce wemos
Modul B - niedzialajacy modul zdjety z plytki wemos

Po podlaczeniu modulu B w tryb wykonywania programu, esp nadal nie resetowal sie poprawnie i nie wstawal z deep sleep
Zamienilem sam ic esp miedzy modulami i modul A nadal dziala a modul B nadal nie dziala.

Wciaz aktualne pytanie o STM

Dodano po 2 [godziny] 5 [minuty]:

khoam napisał:

No dobrze, czy mógłbyś przeprowadzić test na "felernym" ESP zgodnie z poniższym schematem. Do pinów RST i D0 nic więcej nie powinno być podłączone poza tranzystorem.

Nie za bardzo. Nie potrzebuje zewnetrznego sygnalu zerujacego, mam to zrobione w pierwszym poscie (tyle ze na uc, zeby byly dwa sygnaly reset, bo po jednym nie wstaje), rst i tak na module jest podciagniety do vcc. Nie wiem co ten uklad mielby wniesc.

Kod z postu powyzej jednak nie dziala. Tzn. sie dziala jezeli w programie mam tylko deep sleep. Uzylem go w rozbudowanym programie i uklad zaczal sie resetowac w petli (chyba kilkanascie razy i zawisl na amen). Zostane wiec przy rozwiazaniu sprzetowym czyli programie na STM bo to rozwiazanie dziala na wszystkich modulach.

Zdjecie modolow z tej samej dostawy:


Po lewej niedzialajacy po prawej dzialajacy. Roznia sie pamiecia flash. Co ciekawe ktos w dyskusji z linku ktory podalem wyzej powiedzial ze zmienil flash i modul zaczal pracowac poprawnie.
Zdjalem oslone z innego niedzialajacego modulu i ma taki sam flash jak ten na zdjeciu po lwewj stronie (czyli niedzialajacy modul). Mam inny dzialajacy modul ze zdjeta oslona i tam jest jeszcze inny flash.

W przyszlosci podmienie flashe miedzy modulami i dam znac czy to one sa przyczyna. Teraz jednak zostaje przy sprzetowym resecie - srednio 2µA wiecej w deep sleep nie stanowia problemu i jestem zadowolony z takiego wyniku...

Edit
Jednak winowajca okazuje sie byc flash. Zamienilem je miedzy modulami i moduly zamienily sie funkcjonalnoscia - ten co nie dzialal, zaczal dzialac, a ten co dzialal przestal dzialac...

Feralny flash:

khoam napisał:

Czy programy dla ESP tworzyłeś z użyciem Arduino Core, czy też samego SDK? W jakiej wersji?

Arduino. Zbyt malo wazny projekt, zbyt malo czasu, zbyt duza odleglosc do testowania, ograniczona mozliwosc testowania zdalnego i tym samym wprowadzania poprawek aby angazowac w to SDK.