Самопроизвольная перезагрузка ESP8266 при внешних прерываниях с детектора нуля.

[Lipt0n78]

Здравствуйте!
Имеется ESP8266 ESP-07 , силовая часть диммера.

NodeMCU custom build by frightanic.com
    branch: master
    commit: c8037568571edb5c568c2f8231e4f8ce0683b883
    SSL: false
    modules: bmp085,file,gpio,net,node,tmr,uart,wifi
build     built on: 2016-04-05 11:04
powered by Lua 5.1.4 on SDK 1.4.0

Решил сделать сетевой диммер на ESP8266 на принципе пропуска полупериодов(то есть на модуль приходит 50*2= 100 "тиков"), собрал схему, написал код, запустил - работает. Но спустя некоторое время модуль сам по себе перезагружается. Вырезал все лишнее и выяснилось что проблема проявляется при работающем прерывании. Если же импульсы не поступают или прерывание отключено, то модуль нормально работает.



Силовая часть собрана по такой же самой схеме как на картинке, ранее стабильно работала с arduino.

Запитывается модуль так - (БП от телефона 5В => LM1117 3.3В).

Пробовал добавлять конденсаторы в цепь питания как указано в даташите для стабилизатора - не помогло. Запитывал от аккумулятора - то же самое.
Подтягивал все неиспользуемые GPIO через PULLUP - результат тот же.
Пробовал менять прошивку(другая версия с того же сайта) - тоже не сработало.
Менял модуль - безрезультатно .

print('START');
tmr.delay(1000000);

input1=5; --GPIO14
gpio.mode(input1,gpio.INT,gpio.PULLUP);

function dimmer()
print('+');
end    
gpio.trig(input1,"up",dimmer);

Все это выглядит так:

+
+
+
+
+
+
"Кѓ
„!О®фа;М;!s&HфH¶Hш
NodeMCU custom build by frightanic.com
    branch: master
    commit: c8037568571edb5c568c2f8231e4f8ce0683b883
    SSL: false
    modules: bmp085,file,gpio,net,node,tmr,uart,wifi
build     built on: 2016-04-05 11:04
powered by Lua 5.1.4 on SDK 1.4.0
START
Д–Bsп)Bяуг<яКjМ:+]2кюR

NodeMCU custom build by frightanic.com
    branch: master
    commit: c8037568571edb5c568c2f8231e4f8ce0683b883
    SSL: false
    modules: bmp085,file,gpio,net,node,tmr,uart,wifi
build     built on: 2016-04-05 11:04
powered by Lua 5.1.4 on SDK 1.4.0
START
> +
+
+
+
+
+
+
+
+
+

PS. время до перезагрузки колеблется в пределах от 15 до 90 секунд.

Подскажите, пожалуйста, что я упустил.

 

[planar74]

Питание. Все зло от него. На входы тоже должно быть с вероятностью 146% 3,3V.

 

[Lipt0n78]

Подтянул все GPIO к 3,3 - не помогло. ADC в воздухе, чуть позже к земле притяну, попробую.

 

[serrgee]

В коде используется tmr.delay()... Это категорические нельзя, поэтому и зависоны. Нужно применять tmr.alarm() с аппаратными таймерами. Вам нужно разобраться как писать событийно-управляемые программы для NodeMCU.

 

[Lipt0n78]

В коде используется tmr.delay()... Это категорические нельзя, поэтому и зависоны. Нужно применять tmr.alarm() с аппаратными таймерами. Вам нужно разобраться как писать событийно-управляемые программы для NodeMCU.

Просветите меня. Таймер здесь исключительно для первого запуска, как он влияет на последующую работу модуля? Цикла то нет, срабатывает только функция dimmer, вызываемая прерыванием. Нет прерываний - нет работы модуля.
PS. и ADC к земле притянул - то же не сработало.

 

[serrgee]

Что происходит в деталях я сказать не могу. В NodeMCU нужно соблюдать правила кооперативной многозадачности, чтобы работали другие модули прошивки: WiFi и IP стеки, последовательный ввод-вывод и т.д. Если им не давать исполняться, то вся система рано или поздно зависнет или перезапустится вотч-догом. Я наблюдал это в простейших программах.

 

[Lipt0n78]

4020
4021
4022
4023
4024
4025
ZЛ
Aэ3jХюAВNSьЩ1Ќ»9HКIYCб
NodeMCU custom build by frightanic.com
    branch: master
    commit: c8037568571edb5c568c2f8231e4f8ce0683b883
    SSL: false
    modules: bmp085,file,gpio,net,node,tmr,uart,wifi
build     built on: 2016-04-05 11:04
powered by Lua 5.1.4 on SDK 1.4.0
START
ДћBsп^l6уЖЄЖ3L„ѓW6)яR

////////// Здесь происходит затык длительностью в пару секунд.

NodeMCU custom build by frightanic.com
    branch: master
    commit: c8037568571edb5c568c2f8231e4f8ce0683b883
    SSL: false
    modules: bmp085,file,gpio,net,node,tmr,uart,wifi
build     built on: 2016-04-05 11:04
powered by Lua 5.1.4 on SDK 1.4.0
START
> 1
2
3
4
5
6
7
8
9

Интересно почему модуль два раза подряд перезагружается.

print('START');
Tmr1=0
input1=5; --GPIO14
gpio.mode(input1,gpio.INT,gpio.PULLUP);

function dimmer()
Tmr1=Tmr1+1;
print(Tmr1);
end  
gpio.trig(input1,"up",dimmer);

GPIO через резисторы 5,1кОм подтянуты к пинам, ADC к через тот же 5,1кОм к земле.
Задержек в коде уже нет.
Модуль запитан от аккумулятора.

.. а изменений то не видно.
... и осциллографа нет.

 

[serrgee]

@Lipt0n78
Уберите print() из цикла обработки прерывания и посмотрите, будет ли перезагрузка

 

[Lipt0n78]

@Lipt0n78
Уберите print() из цикла обработки прерывания и посмотрите, будет ли перезагрузка

Увы, результат все тот же, перезагружается.
Можно конечно просто включать и выключать нагрузку, но по сути это уже другое устройство с другим функционалом.
Ради интереса попробую завернуть модуль в фольгу, а вдруг сработает .
ЗЫ. так же ведет себя.

 

[serrgee]

@Lipt0n78
Разберитесь в чём причина перезагрузки:

1. ваша программа обработки прерывания
2. помехи по питанию при коммутации нагрузки

Проверьте, что у вас подключен общий провод (земля), увеличьте конденсатор на выходе LM-ки до 470-1000 мкФ и убедитесь что БП способен выдать 500 мА, не подавайте 5-вольтовые уровни на Tx/Rx без ограничивающего резистора 470 ом.

 

[Lipt0n78]

Что вы подразумеваете под программой обработки прерывания?
Без общего провода обмен данными вообще не работает - сыпет мусор в порт вместо читаемых данных.
На LM стоят два конденсатора - керамический и электролит (1000мкФ).
Даже если БП просаживается или вылетает в некоторые моменты, то модуль сейчас все равно запитан от двух аккумуляторов 18650, которые запросто раскаляют обычную булавку при КЗ.
Коммутации нагрузки не происходит - ее просто нет ни в коде, ни в железе - все лишнее отключено.
UART переходник отключал, все равно перезагружается(видно по индикаторному светодиоду на модуле).
Ножку на которую приходят прерывания тоже менял.

У меня LM`ка находится прямо на текстолите модуля с обратной стороны, будет смешно если дело таки окажется в "близком соседстве".
Чуть позже попробую перепаять.

 

[sharikov]

Коммутации нагрузки не происходит - ее просто нет ни в коде, ни в железе - все лишнее отключено.
UART переходник отключал, все равно перезагружается(видно по индикаторному светодиоду на модуле).

Версия 1:
Напряжение в сети далеко не синусоида. Особенно сильно зашумлен переход через ноль. Возможно в момент перехода на вход прерывания поступает дребезг. esp виснет если прерывания поступают слишком часто. Решение: после прихода прерывания запретить прерывания от этой ножки на 1/8-1/4 периода сети.

Версия 2:
современные чипы очень страдают от наносекундных помех. Проходная емкость оптронов достаточна для того чтобы киловольтные наносекундные помехи проходили в изолированную часть схемы и мешали работе микропроцессора. Проверка: отключить силовую цепь или выпаять оптрон. Детектор нуля включен через 2 резистора, они должны гасить помеху.

 

[Lipt0n78]

Версия 1:

Спойлер: text

Напряжение в сети далеко не синусоида. Особенно сильно зашумлен переход через ноль. Возможно в момент перехода на вход прерывания поступает дребезг. esp виснет если прерывания поступают слишком часто. Решение: после прихода прерывания запретить прерывания от этой ножки на 1/8-1/4 периода сети.

Версия 2:
современные чипы очень страдают от наносекундных помех. Проходная емкость оптронов достаточна для того чтобы киловольтные наносекундные помехи проходили в изолированную часть схемы и мешали работе микропроцессора. Проверка: отключить силовую цепь или выпаять оптрон. Детектор нуля включен через 2 резистора, они должны гасить помеху.

Про дребезг тоже думал. На сигнальную ножку, параллельно оптрону пробовал цеплять керамический конденсатор.
Силовую часть давно отпаял. Не вижу толку выпаивать оптрон, если без "тиков" прерывания всё работает.
Как вариант я хочу попробовать считать импульсы с генератора на 555 микросхеме.
Но к сожалению я пока не располагаю временем для того чтобы проверить новые догадки.

 

[serrgee]

@sharikov

современные чипы очень страдают от наносекундных помех.

Где посмотреть подробности про воздействие наносекундных помех?

 

[Сергей Тимофеев]

У меня похожая проблема. http://esp8266.ru/forum/threads/fatal-exception.1355/
Я склоняюсь, что в этом виновата основная прошивка модуля. Точнее не прошивка, а параметры, задающие её работу. Вроде бы на "чистой" ESP глюков не было. Они появились после "активной работы".

 

[nikolz]

если вопрос актуален. поставьте в цикл рестарт WDT

 

[Игорь Голов]

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

Этот таймер останавливает выполнение программы на 10 секунд. Детектор нуля считает что всё зависло и перезагружет всё. Совет, который вам дали по поводу

Это категорические нельзя, поэтому и зависоны. Нужно применять tmr.alarm() с аппаратными таймерами. Вам нужно разобраться как писать событийно-управляемые программы для NodeMCU.

очень правильный. Именно то, что Вам будет нужно. Удачи.

 

[nikolz]

перепишите так:
print('START');
Tmr1=0;
input1=5; --GPIO14;
gpio.mode(input1,gpio.INT,gpio.PULLUP);
----------------------------------
function dimmer()
Tmr1=Tmr1+1;
print(Tmr1);
end
-----------------------------------
gpio.trig(input1,"up",dimmer);
--------------------------------------------
tmr.alarm(1,5000,1,function() tmr.wdclr (); end);

 

[Юрий Ботов]

Только что столкнулся с проблемой непонятного wdt на одном D1. На втором D1 и NodeMCU проблем не оказалось. ТО есть на моем конкретном D1 оказались проблемы с фильтрацией электропитания... А выглядело как отказ реакции на ESP.wdtDisable()