D1 mini не возобновляет работу, как ожидалось, после глубокого сна

Я пытаюсь заставить D1 mini возвращать работу после ESP.deepsleep(). Приведенный ниже код компилируется и дает ожидаемый результат для первого запуска. Через пять секунд после объявления о том, что устройство переходит в спящий режим, на бортовом светодиоде происходит короткая вспышка, и я получаю строку мусора на последовательном мониторе. Будем признательны за идеи, которые можно попробовать.

// Тестирование глубокого сна d1 mini
// D0 и RST соединены

/*  platformio.ini:
  [env:d1_mini]
  platform = espressif8266
  board = d1_mini
  framework = arduino
  monitor_speed = 115200
*/

#include <Arduino.h>

void blink();

void setup() {
  Serial.begin(115200);
  pinMode(D0, WAKEUP_PULLUP);
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  blink();
  delay(1000);
  Serial.println("Going for some deep sleep");
  ESP.deepSleep(5e6); // 5e6 это 5 секунд
}

void blink() {
  digitalWrite(LED_BUILTIN, LOW);
  delay(500);
  digitalWrite(LED_BUILTIN, HIGH);
  delay(500);
}

Как вы можете догадаться, я запускаю это на платформе. Вывод на серийный монитор:

stefan@Cameron ~/.../Projects/Deep sleep $ platformio device monitor --baud 115200
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
Going for some deep sleep
sl␀l��|␀�l�|␂␌␌␄�␄l�␌c|ǃ␃�␛�r�cd�c��gg�doo���␌cpp��$sd{d␛�{��o�c�gbx␀�

При первом запуске светодиод мигает, после кажущегося сброса тоже ничего.

, 👍0

Обсуждение

У меня такая же проблема после глубокого сна. Вот код ошибки @74880bps: epc1=0x40100000, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000 Фатальное исключение (0): но когда я вижу эту проблему, если я вручную нажимаю кнопку сброса или вручную подключаю RESET на GND, плата перезагружается и перезапускает мой код, как и ожидалось. Только пробуждение из глубокого сна вызывает эту проблему. Вы исправили свою проблему? Спасибо,, @gbetous


2 ответа

-1

Попробуйте очистить всю память. Может быть, есть что-то, что портит его.

Я попробовал ваш код, и он у меня работает. У меня нет D1 mini, но я не вижу причин, чтобы он не работал. (по аппаратным причинам)

Я бы включил задержку, а затем выводил новую строку в настройках. Так как ваш цикл print пишется после информации о загрузке и теряется в конце строки.

Как я уже сказал, ваш код у меня сработал. Но я нахожу это более удобным для пользователя. https://raw.githubusercontent.com/wemos/D1_mini_Examples/ master/examples/02.Special/DeepSleep/Blink/Blink.ino

Проверьте еще раз свои соединения. (Я уверен, вы делали это десятки раз)

,

Спасибо. Сделал то, что я думаю, это сброс прошивки, подключив D3 к GND на 5 секунд. Добавлена задержка и Serial.println() в setup(). Те же результаты. Я наткнулся на ссылку, которую вы предложили ранее, но нет никакой разницы, если я поместил все это в setup(). Кажется, дело не только в том, что последовательная связь нарушена, blink() все равно должно произойти, если код попадет туда (и он должен снова сбросить немного позже)., @SEngstrom

Ага. Как я уже сказал, ваш код работает. (хотя мне это не нравится) У вас есть другая плата, которую вы можете попробовать?, @Rudy

Я думаю, что @Rudy прав. Я только что попробовал код на D1 mini, и он отлично работает для меня. Вы можете полностью сбросить прошивку с помощью PlatformIO с помощью такой команды (возможно, вам потребуется изменить серийное имя устройства): ~/.platformio/packages/tool-esptool/esptool -vv -cd nodemcu -cb 115200 -cp /dev/ cu.usbserial-1430 -ce, @romkey

Спасибо, Джон - выполнение этого приводит к: stefan@Cameron ~ $ ~/.platformio/packages/tool-esptool/esptool -vv -cd nodemcu -cb 115200 -cp /dev/cu.usbserial-1430 -ce – esptool v0.4.13 - (c) 2014 гл. Клиппель <[email protected]> настройка платы на nodemcu установка скорости передачи от 115200 до 115200 установка порта с /dev/ttyUSB0 на /dev/cu.usbserial-1430 espcomm_erase_flash открытие порта /dev/cu.usbserial-1430 на 115200 ошибка: невозможно получить доступ к /dev/cu.usbserial-1430, @SEngstrom

кажется, был некоторый успех, но никаких изменений в поведении при запуске кода., @SEngstrom

@rudy - я попробовал другую ранее не использовавшуюся плату и тот же результат. Жаль, что вам не нравится мой код :), @SEngstrom

@SEngstrom ошибка при очистке флэш-памяти означает, что имя последовательного порта (/dev/ttycu.usbserial-1430) неверно - если вы хотите попробовать это еще раз, вам нужно найти правильный вариант для вашей системы. Платформио, вероятно, где-то его печатает. Вероятно, только часть «1430» будет другой., @romkey

@JohnRomkey еще раз спасибо - я выполнил эту команду esptool, но не играл в кости., @SEngstrom

2

Это мусор из-за того, что ESP8266 выводит загрузочную информацию на 76800. Это должно включать причину загрузки и может помочь вам понять, почему код не работает должным образом.

Попробуйте изменить серийную скорость на 76800 в своем коде (чтобы ваши сообщения не превратились в тарабарщину), используйте 76800 на мониторе платформы, и вы сможете по крайней мере увидеть, что D1 говорит, что он делает.

Вы должны увидеть строку, которая заканчивается чем-то вроде:

первая причина: x, режим загрузки: (y, z)

x должен быть равен 1 ("Power reboot"), 2 ("Внешний сброс или выход из глубокого сна" - очевидно, что ты хочешь), 3 ("Software WDT" - сработал программный сторожевой таймер) или 4 ("аппаратный сброс WDT" - сработал аппаратный сторожевой таймер)

режим загрузки указывает, откуда был получен образ среды выполнения — y должно быть равно 3 ("Flash"); что-либо другое действительно маловероятно для вашей установки.

Подробнее об этом см. Причины сброса ESP8266. и обычный фатальный Причины исключения

Если попробуете, отпишитесь, как получилось! Я хотел бы услышать больше о том, что здесь происходит.

,

Большое спасибо! Скорость передачи в бодах подходит для захвата этого «мусора» — это результат после установки последовательной скорости на 76800 везде: `stefan@Cameron ~/.../Projects/Deep sleep $ platformio device monitor --baud 76800 --- Минитерм на /dev/ttyUSB0 76800,8,N,1 --- --- Выход: Ctrl+C | Меню: Ctrl+T | Справка: Ctrl+T, затем Ctrl+H --- Привет, я сейчас в настройке Идти на глубокий сон ets 8 января 2013, первая причина: 5, режим загрузки: (1,6) ets_main.c`, @SEngstrom

Не знаю, как форматировать код в комментариях..., @SEngstrom

Таким образом, причиной сброса было пробуждение из глубокого сна. Отклонение в режиме загрузки - это то, что мне придется покопаться завтра., @SEngstrom

Да, к сожалению, нет хорошего способа форматирования комментариев :( Меня все время кусает. Режим загрузки 1 должен означать, что он пытается загрузиться через UART (загрузить новый код), а не через флэш-память. У вас есть что-нибудь подключенное к D3 или D4? Если вы попытаетесь отключить их или попробовать подключить D3 к 3,3 В через резистор с высоким значением (скажем, 47K или более, значение не должно иметь большого значения). /esp8266/esp8266-wiki/wiki/Boot-Process#esp-boot-modes, @romkey

Таким образом, 1 в режиме загрузки (1,6), по-видимому, означает, что мой d1 mini ожидает загрузки кода из UART, как вы говорите: https://github.com/esp8266/esp8266-wiki/wiki/Boot-Process# esp-boot-режимы Это сообщение не имеет большого смысла для меня. Отправка кода по серийному номеру не похожа на то, что может запросить *правление*. В любом случае - немного разочарован этим - я ценю весь вклад людей, но пока глубокий сон ускользает от меня., @SEngstrom

@SEngstrom - да, плату можно принудительно перевести в режим, в котором она загружает код, предоставленный через последовательный порт, что здесь определенно бесполезно. Поэтому я и спрашивал о линиях D3 и D4 на плате - они куда-нибудь распаяны? Именно они контролируют режим загрузки. Если они ни к чему не подключены, попробуйте принудительно установить высокий уровень D3 и низкий уровень D4 — это должно перевести ESP8266 в режим, в котором он загружается из флэш-памяти SPI., @romkey

Когда у меня высокий уровень D3 и низкий уровень D4, встроенный светодиод загорается и продолжает гореть, и я больше не могу разговаривать с платой. Однако теперь у меня появляется режим загрузки: (3,6) вместо того, чтобы после выдергивания D3, D4 тянет, но все равно останавливается после сообщения о том, что после глубокого сна пробуждение., @SEngstrom

Похоже, между вашим D1mini и моим есть что-то другое. У меня почти нет идей, извините! Как сказал @Rudy, это должно работать (и я вижу, что это работает с той же настройкой). Я опубликую новый комментарий, если я смогу придумать что-нибудь еще, чтобы попробовать., @romkey

Смотрите также: