ESP8266 требует двух перезагрузок, чтобы проснуться от глубокого сна
Я работаю со следующей схемой, используя NodeMCU:
У меня есть перемычка для пайки между RST и BTN. В дополнение к тому, что показано на схеме, контакты 2, 3 и 4 J1 подключены к катодам 3 светодиодов, питаемых через контакт 1 на том же разъеме.
Я использую следующий код для тестирования пробуждения от глубокого сна:
#include <Arduino.h>
void setup() {
delay(1000);
Serial.begin(9600);
Serial.println("start");
ESP.deepSleep(0);
while (1);
}
void loop() {
}
Я строю код с-DDEBUG_ESP_PORT=Serial-DDEBUG_ESP_CORE
и наблюдаю следующее поведение на последовательном порту после запуска:
SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀
Это выглядит так, как я ожидал (за исключением, может быть, для трейлинга ␀?). Потребление тока так низко, как я ожидал от глубокого сна. Теперь я тяну СНАЧАЛА низко, нажав кнопку один раз, и вижу несколько битов мусора (каждый раз разных), выводимых на монитор устройства - больше ничего не происходит:
SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀␀�
В этот момент потребление тока увеличивается от одноразрядных миллиампер до нескольких десятков миллиампер. Тем не менее, полный сброс, кажется, не происходит, и моя программа, кажется, не выполняется снова с самого начала.
Если я сейчас потяну сначала вниз снова со вторым нажатием кнопки, я вижу, что выводится немного больше мусора, прежде чем, кажется, произойдет правильный сброс:
SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀␀�␕{��1S�
SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
start
bcn 0
del if1
usl
enter deep sleep␀
Этот цикл затем повторяется, всегда требуя двух нажатий кнопки для сброса.
Аналогично, если я попытаюсь загрузить новую программу на ESP8266 после того, как она изначально вошла в глубокий сон, загрузка завершится с:
A fatal error occurred: Timed out waiting for packet header
*** [upload] Error 2
Попытка повторной загрузки сразу после этого действительно увенчалась успехом. Следующая загрузка после этого снова завершится неудачей, и так далее.
Основываясь на этих наблюдениях, мне кажется, что ESP8266 не полностью сбрасывается при первом же нажатии кнопки, или он действительно сбрасывается, но входит в какое-то состояние, в котором по какой-то причине не выполняет мое приложение.
Какие могут быть причины? Это то, что я могу обойти либо в аппаратном обеспечении, либо в коде?
Спасибо!
@Florian Ragwitz, 👍3
Обсуждение0
- NodeMCU 12E V2 Энергосбережение
- ESP8266 тратит 10 мА, даже если он находится в режиме глубокого сна
- Сброс глубокого сна с датчиком удара
- часы nodemcu GPIO6
- Как заставить 5-вольтовое реле работать с NodeMCU
- ESP8266 не подключается к Wi-Fi
- Разница между этими двумя платами NodeMCU?
- NodeMCU - использовать кнопку flash в качестве входного сигнала в loop()
Добавьте " Серийный.промыть();` после печати. В противном случае вы никогда не увидите, как на нем что-либо печатается., @Majenko
@Majenko Я действительно вижу последовательный вывод, который я ожидаю перед сном, и с помощью других индикаторов, таких как светодиоды или зуммер, чтобы узнать, выполняется ли моя программа повторно после сброса, имеет одинаковое поведение, требующее двух сбросов., @Florian Ragwitz
случайные идеи: может потребоваться жесткое включение gpio 0 и 2. может потребоваться заглушка на vcc, сначала и т. Д. Может быть включен шум 16. Это может быть энергозатратное приложение; сохраняется ли проблема без зуммера и светодиодов?, @dandavis
В итоге я вытащил ESP8266 из цепи, чтобы проверить поведение сброса в изоляции и сравнить его с другими ESP8266. Оказывается, что только у одной единицы из 6, которые я протестировал, было такое поведение. Установка другого ESP8266 обратно в ту же схему работает просто отлично, и требуется только один сброс. Я не уверен, что, возможно, был какой-то ущерб этому блоку, но просто замена компонента была более практичной, чем дальнейшая его отладка., @Florian Ragwitz
добавьте задержку(500) после последовательного.начните ждать, пока CH340 проснется. в противном случае отпечаток будет потерян. и добавьте функцию flush() после печати, чтобы дождаться ее отправки перед сном., @Juraj