[jcxz 184]

1 час назад, gte сказал:

Может совпадение, но все осциллограммы при зависании приходятся на момент, когда  монитор отпускает сигнал сброса и напряжение на выводе reset подрастает.

Нормальный монитор должен дождаться установления минимального допустимого напряжения и после этого ещё сделать выдержку в пару сотен мсек. И только когда напряжение находится в норме в течение не менее чем эта выдержка - только после этого отпустить RESET.

С таким алгоритмом работы не должны быть страшны никакие провалы, когда бы они не случились. Если конечно схема устройства корректная.

 

PS: Может вы вообще не там ищете? А если например - виновата кривая прошивка, которая входит в ступор например от каких-то помех по интерфейсам связи (UART, etc.), возникающих в моменты переключений питания?

Или может у вас есть паразитная запитка, через какие-то ноги МК: когда основное напряжение питания падает ниже порога удержания RESET-а супервизиром, а паразитная запитка в это время продолжает оставаться активной?

PPS: Всё это - гадания на кофейной гуще.  Хоть бы схему показали, что-ли.....  

[gte 6]

18 часов назад, jcxz сказал:

Нормальный монитор должен дождаться установления минимального допустимого напряжения и после этого ещё сделать выдержку в пару сотен мсек.

Вы меня не поняли, пауза есть, как положено. Но внешние мониторы питания, не скажу что все, но те, что я смотрел, при снижении питания ниже некоторого порога начинают отпускать вывод сброса и он плавно сравнивается с остатком питания. У моего это от 1,1В, видел от 0,8. По совпадению или нет, зависание происходит в момент подачи повторно сетевого питания как раз в момент отпускания монитором сигнала сброса. Скорее это совпадение, но такой факт есть.

18 часов назад, jcxz сказал:

И только когда напряжение находится в норме в течение не менее чем эта выдержка - только после этого отпустить RESET.

С таким алгоритмом работы не должны быть страшны никакие провалы, когда бы они не случились. Если конечно схема устройства корректная.

После того, МК как завис, сброс не помогает, только снятие питания, при перебое питание совсем до нуля снизится не успевает. Если провал питания длительный и питание снизится до нуля, все в норме. Внешних интерфейсов нет, только двоичные с развязкой.

 

18 часов назад, jcxz сказал:

PS: Может вы вообще не там ищете? А если например - виновата кривая прошивка, которая входит в ступор например от каких-то помех по интерфейсам связи (UART, etc.), возникающих в моменты переключений питания?

 

Пока перерыв, отложил на завтра. Т. е. проблему я устранил (тупо добавил электролиты в питание, оказалось полезно после dc-dc с 15В на 5В перед аналоговым стабилизатором 5В на 3,3В) , но причину не нашел. Наводок, кстати, в этот момент особых и нет, так как reset появляется вовремя и зарядка сетевой емкости при повторном включении производится через резистор 100Ом. Может dc-dc виноват, может времена спада роста напряжений изменились, может еще что, поищу, если время позволит. сейчас или позже.

 

18 часов назад, jcxz сказал:

Или может у вас есть паразитная запитка, через какие-то ноги МК: когда основное напряжение питания падает ниже порога удержания RESET-а супервизиром, а паразитная запитка в это время продолжает оставаться активно

 

Паразитное может быть через транзисторный ключ  с +15В, но на ней в это момент порядка вольта.

18 часов назад, jcxz сказал:

PPS: Всё это - гадания на кофейной гуще.

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

[jcxz 184]

38 минут назад, gte сказал:

По совпадению или нет, зависание происходит в момент подачи повторно сетевого питания как раз в момент отпускания монитором сигнала сброса. Скорее это совпадение, но такой факт есть.

И что? Пускай "в момент отпускания". Подаём повторно питание - супервизор должен опять сформировать импульс сброса длительностью не менее заданной. И по его завершении МК должен начать функционировать.

38 минут назад, gte сказал:

После того, МК как завис, сброс не помогает

Импульс сброса на ноге "RESET" МК не помогает??? 

38 минут назад, gte сказал:

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

Состояний таких быть не должно. Другое дело, что программа может вести себя по-разному при разных типах сбросов.

Например: При сбросе по вкл. питания, исходное содержимое ОЗУ может быть равно определённой константе (например = 0), а при сбросе по сигналу RESET (без предварительной просадки питания), там могут быть случайные значения, оставшиеся от предыдущего цикла работы программы. Так как по RESET-у память МК как правило - аппаратно не обнуляется. И если в программе есть баг (какая-то память не инициализируется, а предполагается, что она имеет значения как после вкл. питания), то после RESET-а без снятия питания, она может повиснуть.

Так что: Такое поведение вполне может быть следствием бага в прошивке.

[gte 6]

28 минут назад, jcxz сказал:

И что? Пускай "в момент отпускания". Подаём повторно питание - супервизор должен опять сформировать импульс сброса длительностью не менее заданной. И по его завершении МК должен начать функционировать.

Импульс сброса на ноге "RESET" МК не помогает??? 

Внешний монитор дает сброс. Вручную непосредственно на ресет и на вход сброса монитора, все это не дает никакого результата. На на ногах кварцевых генераторов МК генерации нет, программа точно не запускается, ну или сразу гасит генерацию. Помогает только снятие питания  с процессора.

28 минут назад, jcxz сказал:

Состояний таких быть не должно. Другое дело, что программа может вести себя по-разному при разных типах сбросо

 

Тем не менее, при увеличении емкости даже на 100 мкФ по 5В, из которых получаются 3,3В,  это добавка всего 1/4,  зависания пропадают.

[jcxz 184]

10 минут назад, gte сказал:

На на ногах кварцевых генераторов МК генерации нет, программа точно не запускается, ну или сразу гасит генерацию. Помогает только снятие питания  с процессора.

Генератор в этих МК должна запускать программа. Если он не запускается - видимо она повисла ещё не дойдя до его запуска.

В 24.05.2023 в 18:00, gte сказал:

В режиме отладки все просто вылетает  и больше не подключается. Используется Eclipse JlinkGDBServer.

А если на уже нормально работающее устройство, подать импульс RESET (например - через тот же JTAG) без дёрганья питания - оно корректно перезапускается?

 

PS: Я бы начал с того, что расставил бы в коде прошивки контрольные точки. Прям от самого старта, от вектора сброса. В которых зажигал бы разные светодиоды (или просто на ноги какие-то уровни выводил-бы если светодиодов нет). И выяснил - на каком шаге программа виснет?

[Plain 168]

Похоже, схему мы так и не увидим.

А если вообще, то бывают ИС, которым очень не нравятся напряжения на выводах в отсутствие питания, и при этом речи о защёлкивании нет.

[gte 6]

1 час назад, jcxz сказал:

Генератор в этих МК должна запускать программа. Если он не запускается - видимо она повисла ещё не дойдя до его запуска.

Это понятно, но с того момента, как я это все  делал и  писал, прошло более 10 лет и это не основной род деятельности, но приходится поддерживать, сейчас альтернативы особо нет. Был тогда период их производства, работают с тех пор круглосуточно, за исключением двух в одном месте, у которых были провлемы при авариях в питающей сети. Теперь подозреваю, что процессор не перезапустился и это и было причиной того, что выгорел зарядный резистор сетевого конденсатора. Меры против этого приняты аппаратно, но выяснять причину, видимо, придется по новой.

 

1 час назад, jcxz сказал:

А если на уже нормально работающее устройство, подать импульс RESET (например - через тот же JTAG) без дёрганья питания - оно корректно перезапускается?

Да. Никаких пробем не было ни при нормальном запуске, ни при отладке, ни при работе в условиях цеха. Подозреваю, что если бы для проверки была сделана приспособа для тестирования строго по ГОСТ на провалы питания, то опять бы ничего не всплыло. А здесь передергивание розетки с попаданием в период от 50 до 300-500 мс, судя по осциллограммам, с соответствующим дребезгом. Все осциллограммы с зависанием очень похожи - появление сети через 100 - 150 мс (реально диапазон немного уже) после провала 3,3В, затем появляется питание, затем сброс отпускает, но программа уже нормально не запускается.

1 час назад, jcxz сказал:

PS: Я бы начал с того, что расставил бы в коде прошивки контрольные точки. Прям от самого старта, от вектора сброса. В которых зажигал бы разные светодиоды (или просто на ноги какие-то уровни выводил-бы если светодиодов нет). И выяснил - на каком шаге программа виснет?

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

[jcxz 184]

1 минуту назад, gte сказал:

А здесь передергивание розетки с попаданием в период от 50 до 300-500 мс, судя по осциллограммам, с соответствующим дребезгом. Все осциллограммы с зависанием очень похожи - появление сети через 100 - 150 мс

Кстати - по симптомам очень похоже на зависания из-за воздействия помех. Был как-то у меня проект, в котором не было внешнего WDT. А был только WDT на МК. Который программировался и разрешался при старте программы. Обычно работало, но иногда висло вот как раз в таких случаях, как вы описываете - при нечётком снятии питания (с дребезгом). Потом начали уже полномасштабные испытания на микросекундные помехи и воздействие воздушных разрядов. Так вот - когда начали с ИГЭ-15.2 подавать пачки помех, то виснуть начал очень часто: первые импульсы пачки приводили к сбросу МК, а последующие его вешали до момента разрешения WDT. И картина была такая же - подаёшь пачку - МК повис, даже генератор не запустился и WDT не работает. Вис он ещё на этапе выполнения ROM-кода, ещё не дойдя до пользовательской программы.

Пока полностью схему не переделали, добавив неотключаемый внешний WDT, добиться не зависания не удавалось.

У LPC-шек кстати тоже сначала после сброса ROM-код выполняется.

[gte 6]

1 час назад, Plain сказал:

Похоже, схему мы так и не увидим.

Это приведет только к контрпродуктиву.

1 час назад, Plain сказал:

А если вообще, то бывают ИС, которым очень не нравятся напряжения на выводах в отсутствие питания, и при этом речи о защёлкивании нет.

Я понимаю это, но кроме 3,3 вольт напрямую без опторазвязки, подключены два ключа, один с реле на +15В, здесь питание сразу падает, примерно, на 1В и ключ на реле +5В. Цепь 5В я не контролировал и именно с нее получается 3,3В и на нее я повесил конденсатор, кстати. Но вроде бы это реле я выдергивал с панели, но уже неуверен, но на выводе процессора идущего к базе ключа реле (и 5В и15В) стоит резистор 2кОм, как раз для прижатия пинов к земле.

11 минут назад, jcxz сказал:

гкогда начали с ИГЭ-15.2 подавать пачки помех, то виснуть начал очень часто: первые импульсы пачки приводили к сбросу МК, а последующие его вешали до момента разрешения WDT. И картина была такая же - подаёшь пачку - МК повис, даже генератор не запустился и WDT не работает. Вис он ещё на этапе выполнения ROM-кода, ещё не дойдя до пользовательской программы

 

Монитор питания и WDT внешний. А куда подавали микросекундные помехи при зависаниях? Воздушные и контактные могу успеть проверить, прям от этого же блока, он 20 кВ и 7,5 мА. А для микросекундных деталей не хватает.

[jcxz 184]

12 минут назад, gte сказал:

Монитор питания и WDT внешний. А куда подавали микросекундные помехи при зависаниях?

В корпус (точнее - в его напылённую металлизацию, так как сам он был пластиковый), в разъёмы, в светодиоды (торчащие наружу из корпуса), в интерфейсные провода. Воздушные. От кондуктивных такого не было.

Хуже всего было поведение при подаче разрядов в напылённую металлизацию на корпусе. насколько помню...

[gte 6]

Спасибо, видимо все же наносекундных, судя по ИГЭ 15.2. У меня корпус металлический, более страшны микросекундные, так как есть защита от пробое в нагрузке и в широком диапазоне выходных напряжений, соответственно, может сработать даже от этой причины. Написано про это в инструкции, должно учесться.

[Plain 168]

1 час назад, gte сказал:

на нее я повесил конденсатор

Из чего следует, что виновато подключение монитора и не тот его номинал — надо сбрасывать по провалу на входе стабилизатора, потому что работоспособность любого МК гарантируется лишь при номинале питания.

[HardEgor 66]

6 часов назад, gte сказал:

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

А что показывает в это время выход RSTOUT ?

RSTOUT — This is a 1.8 V pin. LOW on this pin indicates LPC2364/66/68 being in
Reset state.

[gte 6]

5 часов назад, Plain сказал:

Из чего следует, что виновато подключение монитора и не тот его номинал — надо сбрасывать по провалу на входе стабилизатора, потому что работоспособность любого МК гарантируется лишь при номинале питания.

Монитор питания TPS3828-33  совмещен с WDT имеет порог срабатывания по описанию 2,93 В и подключен, естественно, к питанию 3,3В, которые получаются стабилизатором из тех 5В, где сработал конденсатор, ставил сначала 470,0, но помогает и 100,0. Конечно, можно мониторить 5В и отключать процессор еще до того, как провалится 3,3В, но  что есть, то есть и нет формальных причин так подключать монитор питания. В следующей итерации, возможно и сделаю таким образом для подстраховки. Близко к выводам источника 5В стоит 10 мкФ танталовый конденсатор и керамика 0,1. Мне вот сомнительно, что электролит в 100,0 в довесок к почти 300,0 на этой линии подавил какую то помеху, скорее сыграло изменение скоростей изменения напряжения, но всякие чудеса бывают.

[gte 6]

В 26.05.2023 в 20:32, HardEgor сказал:

А что показывает в это время выход RSTOUT ?

RSTOUT — This is a 1.8 V pin. LOW on this pin indicates LPC2364/66/68 being in
Reset state.

Проверю позже, сейчас катастрофически нет времени.