ESP-01 просыпается от глубокого сна и затем зависает

Question

ESP-01 просыпается от глубокого сна и затем зависает

esp8266

Я нашел несколько других сообщений от людей с той же проблемой, но не могу найти ответа.

У меня есть небольшая партия плат ESP-01, продаваемых Inland, и я хочу использовать на них режим глубокого сна.

Я припаял небольшой медный провод от контакта 8 (то есть GPIO 16) к RST. На одной плате я припаял его напрямую, на другой я припаял вывод 8 и RST к двум сторонам 2-контактного заголовка, чтобы я мог использовать перемычку в случае, если я хочу отключить GPIO 16 от RST.

Я мигаю следующим простым кодом (используя Arduino IDE 1.8.12), который является самым простым тестом режима глубокого сна, который я могу придумать.

void setup() 
{
   Serial.begin(74880);
   Serial.setTimeout(2000);

   while(!Serial) { }
  
   Serial.println(
     "I'm awake, but I'm going into deep sleep mode for 15 seconds");

   ESP.deepSleep(15e6); 
}

void loop() {
}

При запуске последовательный монитор показывает

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3664, room 16 
tail 0
chksum 0xee
csum 0xee
v39c79d9b
~ld
I'm awake, but I'm going into deep sleep mode for 15 seconds

Через 15 секунд последовательный монитор показывает

ets Jan  8 2013,rst cause:2, boot mode:(3,6)

и больше ничего. После этого штука зависает, и больше ничего не происходит.

Итак, похоже, что настройка выполняется, последовательный монитор печатает сообщение, mc переходит в глубокий сон, через 15 секунд он просыпается от сброса, но не проходит настройку снова, следовательно, не печатает сообщение и не возвращается в спящий режим.

Вот несколько комментариев. Проблема не имеет ничего общего с Wi-Fi, MQTT и т. Д., Я пробовал много причудливых скетчей, используя все это, у меня такая же проблема, несмотря ни на что, вышеизложенное - это моя дистилляция к простейшей демонстрации проблемы глубокого сна.

Я прошил программу с помощью Arduino IDE, Platform IO и esptool.py из командной строки. Это не имеет никакого значения.

Возможно, у меня есть проблемы с пайкой, но я довольно хорошо разбираюсь в пайке и переделке SMD, и я повторил эту работу на нескольких модулях ESP-01, проверил и протестировал их мультиметром и т. Д. и все с одним и тем же результатом.

Я не вижу проблем с моим кодом или IDE, у меня есть партия плат Lolin Nodemcu, и этот скетч отлично работает на всех них. В этом случае я просто подключаю GPIO 16 к RST с помощью перемычки, программа печатает сообщение, спит в течение 15 секунд, просыпается, печатает его снова, возвращается в спящий режим еще на 15 секунд и т. Д.

Это просто плохие платы? Я читал кое-что, что говорит о том, что флэш-чипы могут быть паршивыми, и если я заменю их, это может помочь? У меня есть соблазн выбросить эти платы и купить несколько D1 mini, но я видел несколько сообщений от людей, которые говорят, что у них была такая же проблема с D1 minis. Если проблема заключается в плате, есть ли какие-либо рекомендации для производителей или продавцов, которые продают лучшее качество?

@RobT, 👍3

Обсуждение

1) У вас случайно не было чего-нибудь, подключенного к сбросу PIN, например, от последовательного адаптера USB-TTL? 2) Попробуйте использовать CH_PD вместо СБРОСА PIN, чтобы посмотреть, работает ли это? Для CH_PD это будет зависеть от того, есть ли у вас ESP-01 или ESP-01S (у которого уже есть тяговый резистор на CH_PD)., @hcheung

в то время как (!Serial) { } ничего не делает на esp. почему у вас есть Serial.setTimeout (2000);? дайте esp полностью запуститься перед сном. Я предполагаю, что он все еще находится в процессе автоматического подключения к последней запомненной точке доступа., @Juraj

@hcheung Плата - это ESP-01, а не ESP-01S. Я программирую его с помощью простой мигалки USB-TTL, также продаваемой компанией Inland, подключенной к USB-порту моего Macbook. Когда плата подключается к мигалке, ПЕРВЫЙ вывод вытягивается до 3v3 с помощью резистора 12 Ком. Итак, я должен попробовать подключить GPIO 16 или CH_PD вместо RST и посмотреть, что произойдет?, @RobT

@Juraj Хороший вопрос! Я не уверен, я скопировал код, так как я не совсем уверен, что я делаю. Я закомментировал строки с помощью while(!Серийный номер)... и Serial.setTimout .... и результат не изменился. Как я уже упоминал, я могу запустить один и тот же скетч на нескольких платах ESP8266 Nodemcu, и он работает нормально, поэтому я решил, что проблема не в программном обеспечении., @RobT

Мне нужно внести поправки в одну вещь: Я сказал: "Через 15 секунд он просыпается при сбросе, но ...". Это не совсем понятно. В качестве эксперимента я запустил скетч на плате nodemcu (где он отлично работает), но я НЕ подключал GPIO 16 к RST с помощью перемычки. Результат точно такой же, он переходит в спящий режим, затем через 15 секунд печатает ets 8 января 2013 года, первая причина: 2, режим загрузки: (3,6), и больше ничего, а затем зависает. Другими словами, плата ESP-01 ведет себя точно так же, как если бы GPIO 16 НЕ был подключен к RST., @RobT

на esp-01 ввод-вывод 16 не подключен к сбросу, @Juraj

@juraj Я не совсем понимаю, что ты имеешь в виду. Вы имеете в виду, что GPIO 16 по умолчанию не подключен к сбросу на плате ESP-01, или вы имеете в виду, что он не должен быть подключен? Очевидно, что он не подключен по умолчанию. Согласно спецификации ESP8266, GPIO 16 необходимо подключить к сбросу, чтобы включить выход из глубокого сна. Моя цель - заставить чип пробудиться от глубокого сна., @RobT

это не связано. вы можете подключить его, если сможете припаять к ножке чипа. он должен быть подключен для выхода из глубокого сна. это обходной путь для ошибки в базовом загрузчике esp8266. этот загрузчик не может быть обновлен, и он зависает при внутреннем пробуждении., @Juraj

@juraj Это имеет смысл, что это обходной путь для ошибки. Когда чип только разрабатывался, можно было подумать, что его можно было бы сделать так, чтобы он выходил из глубокого сна без необходимости подключения к внешним устройствам., @RobT

2 ответа

@*RobT* · Answer 1 · 2020-09-23 06:19-00:00

Я пришел к выводу, что эти платы плохие. Я написал простой скетч, который включает светодиод на 3 секунды, затем погружается в глубокий сон на 12 секунд, а затем просыпается. У меня есть партия из 3 плат Lolin ESP8266 nodemcu, и скетч отлично работает на всех них. Светодиод загорается на 3 секунды, затем гаснет на 12 секунд, затем снова загорается и т. Д. Кроме того, с помощью амперметра я многократно измеряю потребляемый ток около 80 мА при включенном светодиоде и около 4 мА при выключенном.

Однако --- У меня есть еще одна партия из пяти плат ESP-01. Я припаял тонкий медный провод к GPIO 16 и к выводу сброса, использовал тот же код, ту же настройку, источник питания, светодиод и т. Д. Свет горит в течение 3 секунд, затем гаснет в течение 12 секунд, затем снова включается и остается включенным, а затем никаких дальнейших изменений не происходит. Кроме того, потребляемый ток в течение первых 3 секунд составляет около 80 мА, но когда свет снова загорается и контроллер зависает, потребляемый ток составляет около 40 мА.

Кстати, я протестировал платы nodemcu, которые отлично работают, с этим скетчем, но отключил перемычку от GPIO 16 или RST, и она ведет себя точно так же, как платы ESP-01, включая потребляемый ток 40 мА в состоянии зомби. Таким образом, похоже, что проблема на платах ESP-01 заключается в том, что 16-контактный вывод GPIO просто не подключен к RST. Однако я припаял все пять этих вещей несколько раз, и я стал чертовски опытным в пайке этого маленького штифта, и я на 99,999999% уверен, что у меня есть провод, припаянный к штифту, без мостов, ничего не жарил и т. Д.

@*Krazy OldGuy* · Answer 2 · 2020-12-14 00:55-00:00

Не обязательно ответ, но есть на что посмотреть: проверьте идентификатор производителя flash на вашей плате. Я подозреваю, что когда некоторые флэш-чипы выходят из режима приостановки, они находятся в более низком режиме привода, чем при первоначальном включении питания. По крайней мере, один человек исправил свой "режим зомби", заменив flash другим поставщиком. Никто еще не пытался это сделать.

У меня есть внутренний ESP-01S, который сообщает MID = 0x5E (предположительно Zbit), и он неоднократно выходит из Глубокого сна. Вот все идентификаторы производителей, которые я знаю или видел:

Winbond EF GigaDevice C8 Пуйя 85 Яркая Луна 53 БергМикро Е0 XMC 20 XTX 0B Эон 1С Шанхай Fundan A1 Macronix C2 Хуа Хун Чжисинь 68 ISSI 9D Paragon E0 (то же, что Berg - oopsie или клон?) Zbit 5E Zetta BA

esptool.py --port /dev/ttyUSB0 flash_id (linux) esptool.py -p COMx flash_id (Windoze)

Примечание: дешевые мини-платы D1 с модулями no-name ESP-12F, наводняющими eBay, Aliexpress и другие места, сообщают о flash XTX, и у них есть подтягивание 5.6K на EXT_RSTB, которое сократит ПЕРВЫЙ импульс от GPIO16, а также затруднит попадание на уровень, который будет обнаружен как а НИЗКИЙ уровень обусловлен резистором серии 470 Ом. Мы не уверены, является ли это flash или подтягиванием с низким значением (обычно 10 или 12K на других платах / модулях), что вызывает проблемы с этими платами. Обычно, если RST не считается НИЗКИМ после глубокого сна, вы получите сообщение "ets_main.c" при загрузке, прежде чем оно зависнет.

У меня есть клон D1 Mini Pro, у которого есть flash, которая сообщает MID = EF (Winbond), хотя маркировка на flash ничего не может найти на сайте Winbond, только в местах продажи дешевой flash. К счастью, D1 Mini Pro также успешно выходит из глубокого сна.