Здравствуйте все!

Посмотрел на форуме все, что касается RESET для STM32.
Внятного решения не нашел.

Посоветуйте пожалуйста!
Плата сделана на STM32F407VGT.

1. При включении питания проходит сброс, формируется устойчивый фронт, но процессор не стартует.
При нажатии на кнопку RESET , фронт формируется аналогичный, программа выполняется как и надо.

2. При нажатой кнопке RESET включаем питание, потом отпускаем,фронт формируется, но процессор не стартует.

3. Дополнительно еще поставил супервизор с задержкой 350 мс, фронт RESET немного более крутой,
но процессор все равно не стартует при включении.

Но самое печальное что из 20 экземпляров плат всего 2 так себя ведут.

На одной из плат поменял процессор, но ничего не поменялось.
Все обвязки для RESET и BOOT0 перепаял.

В каком направлении копать?

Спасибо.

..повесьте дополнительные конденсаторы на ножки питания контролера, может поможет.

Напишите короткую программу получения импульсов на ножке процессора и поместите её в обработчик вектора RESET - до всех инициализаций. И посмотрите, виснут ли Ваши два экземпляра.

остался кварц и его цепи - перебросьте с заведомо рабочей платы
ну и возможно "грязное" питание

Увеличьте конденсатор в цепи сброса- не хватает времени. Было тоже самое только на LPC.

"Не стартует" - это внешнее проявление неисправности. Подключитесь отладчиком "на лету" и посмотрите, чем занята ваша программа.

Цепи питания перепаял, на всех ножках питания 0.1 мкф + 3 тантала на кристалл, емкость которых увеличил.

Кварц и конденсаторы менял.
Супервизор дает сброс 350 мс, куда больше.

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

по совету выше, залейте контрольный бинарник, по которому можно судить об успешном старте + визуальный осмотр под микроскопом и измерение всех номиналов в окружение stm32 отвечающих за работу + контроль уровней в ключевых точках..

У 407 как минимум две ревизии "A" и "Z".
Было такое с ревизией "А". Лечение описано в ES.

А что такое ES?

errata sheets?

Так точно!
Уже не помню и от дома сейчас далеко, но может быть, что в ревизии Z вывод PDR (вроде так называется 99 или 100 нога) нужно подключить к GND, а в ревизии A к VCC. Или все наоборот.

Как-то уалось решить проблему? У меня подобная ситуация с STM32F100C8T6- стартует после нажатия кнопки ресет, так же нормально стартует при заливке прошивки (с включенной опцией RESET в свойствах ST-LINK). Но при подаче питания не стартует.

Мы STM32F100C8T6 используем ведрами - ничего подобного в железе замечено не было.
Варианта два:
1. Неисправен МК (брак и т.п.);
2. Ошибка в прошивке (зависает в цикле ожидания чего-либо, HardFault или другое исключение).

Попробуйте другой экземпляр МК и/или простейший тестовый софт (мигание светодиодом с задержкой в виде цикла).

попробую другую прошивочку. Другой экземпляр нет возможности попробовать-(. Возможно моя тестовая платка с али с неправильными цепями сброса? Возможно такое?
Дебаг
P.S. попробовал другую прошивочку залить - все отлично мигает светодиодик мой при подаче питания. Значит проблема в моей программе. Как бы отследить эту ошибку? Дебагер начинает после ресета работать и все работает прекрасно..а вот подачу питания как отследить...

получается стартап разный после подачи питания и после reset? Я пользуюсь библиотеками CMSIS которые к кейлу прилагаются. и как-то не могу файл найти stm32f10x_it - в нем прерывания все. Может с этим связано? У меня проект пока без прерываний.

без прерываний у вас не работает библиотечная функция которая крутит миллисекундный таймер, и как следствие у вас все таймауты что в библиотечной инициализации на этом таймере - находятся в вечном простое, там куча while с выходом по таймауту или удаче, любая неудача и у вас висяк...

Это речь о systick таймере? я не пользуюсь им. Но именно при нажатии ресет все идеально а при подаче питания не стартует и как отладить такое, куда улетает программа ума не приложу.

Так уж и два? Я могу ещё парочку подкинуть:
3. Косяки в схеме (плавающая ножка BOOT0, к примеру)
4. Умопомрачение (гляжу в книгу - вижу фигу)
5. И т.д. и т.п.

4 и 5 наиболее вероятны
3 вытекает из 4,5

Упомяну такую вещь как скорость нарастания напряжения питания. Для некоторых контроллеров (stm32f103 например) - по барабану, запустится всегда. А для других контроллеров (stm32f207) этот параметр требуется выдерживать более жестко. Была у меня платка от терраэлектроники на этом проце, которая, из-за неудачного стабилизатора, запускалась через раз. При этом использовался старый линейный лабораторный источник питания. А вот если использовал хороший импульсный, то плата стартовала всегда.

Зависающая программа ваша? Исходники есть? В исходниках функции SWD не заблокированы?
Если SWD не заблокирован, то можно на лету подключиться к зависшей программе (без передергивания по RESET).
Так можно узнать адрес цикла, где все висит для дальнейшего анализа. Предварительно неплохо бы получить листинг программы.

Программа моя. Хочу признаться что я не имею большого опыта в программировании STM32.
Листинг прикладываю. Я в общем-то пользовался стандартной инициализацией от Кейла. Включил только тактирование моей периферии и немного кода работы c uart - i2c - spi.
возникла идея откуда может быть проблема - и для микросекундных задержек использую dwt по этой статье https://kbiva.wordpress.com/2013/03/25/micr...tion-for-stm32/.
Возможно там собака порылась

Здравствуйте, все! Кажется, у меня есть решение этой проблемы. Битый час возюкался с ней. Все перепробовал. Я не вполне уверен, что так везде, но у меня стал запускаться после подачи питания тогда, когда GPIO стали инициализироваться раньше всей остальной периферии. Как только в main переставляю инициализацию GPIO на первое место -- сразу все работает, возвращаю обратно -- не работает. Если не лень -- попробуйте кто-нибудь еще, отпишитесь. Тестил на камне STM32F100C8T6.

День добрый всем !
Попробую освежить эту тему...
У меня с кристаллом STM32F042 наблюдается весьма странная картина при запуске устройства: супервизора сброса на схеме нет, вход сброса только подтянут к VCC и есть кнопка сброса, между входом питания и МК есть LDO-стабилизатор 3.3В. Схему не я разрабатывал, я пишу только программу устройства, поэтому прошу ногами не пинать за схемотехнику....
При запуске с отладчика SWD или после нажатия на сброс - все работает как надо, при подключенном к блоку питания устройстве и включении БП штатным тумблером - тоже все запускается и нормально функционирует...
Но, если я выдергиваю штекер включенного блока питания и снова вставляю, то устройство вроде бы и запускается, но не все работает нормально при этом - возникает затык программы при приеме данных с UART (через прерывание). Отследить этот момент в отладчике не могу, т.к. отладчик на лету не подхватывается (не совсем понял про блокировку SWD из предыдущего поста...), а при запусе не стартует вместе с устройством.
Понимаю, что засада где-то кроется в формировании сброса внутри кристалла узлом POR и вероятно имеет место короткое время нарастания напряжения питания, поэтому повесив на вход сброса электролит 47мкФ (22мкФ оказалось мало), добился вобщем положительного результата, но неясности и ощущение костыля без гипса при поломанной ноге все равно остались ...

Вы, похоже, ответ сами написали:

У Вас идет короткая просадка напряжения питания, но не до нуля, половина кристалла встает в раскоряку, а reset не вырабатывается, или очень короткий. Так что правильный ответ - супервизор. В крайнем случае, добавьте еще диод на reset, чтобы конденсатор быстро разряжался.

Странное там у вас распределение обязанностей - программист ищет косяки схемотехника, обращаясь на соотв. форуме, а что же делает схемотехник? На форумах программистов ищет косяки (если есть) в вашем софте?


Нажмите для просмотра прикрепленного файла

В простых устройствах обычно достаточно на вывод NRST повесить лишь один конденсатор 0.01мк (к GND разумеется), внешний резистор там не нужен (он есть внутри МК).
Это увеличивает время импульса сброса МК, пока питание не стабилизируется.
А в ответственных девайсах, как тут уже заметили, нужен внешний супервизор, особенно, если питание Vdd нарастает слишком медленно.

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

Документация? Не, не читали. А в ней английским по белому написано, что время нарастания питания не критично, критично только время спадания (да и то к таким скоростям вы даже при желании не приблизитесь). Также там написано, что есть встроенный супервизор и указаны его пороги.
Нажмите для просмотра прикрепленного файла

Что это вообще за привычка чуть что вешать на сброс огрмные емкости? Выкиньте свои 47 мкФ, процессор сам себе формирует импульс сброса нужной длительности, более того - он выдает его наружу через эту же ногу RESET Ну максимум там 0.1 мкФ может быть максимально близко к процессору если дорожка от кнопки до ножки длинная. Я бы и кнопку сброса тоже выкинул вместе с дорожкой до ноги процессора и конденсатором - на этапе отладки можно отладчиком сбрасывать, а в работающем устройстве зачем она нужна?

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

Неправда. Он всего лишь давит импульсные помехи на входе. За питанием следит схема сброса по включению питания (POR).

Т.е. внутренняя схема входа сброса нарисована неточно (условно) и поэтому емкость внешнего кондера не влияет время на нахождение мк в сбросе?

Влияет. Но это никак не связано с "питание не стабилизируется".

Т.е. принудительно удержание мк в сбросе вообще не помогает при слишком медленном нарастании напряжения питания?

Посмотрите на картинку в моем сообщении. Для этих МК скорость нарастания питания не критична. Поэтому "удерживать МК в сбросе" не нужно. Совсем.

Убедили ))

Но итог от этого не меняется: или небольшой конденсатор (я ставлю 0.01u) для защиты от помех по цепи сброса или нормальный внешний супервизор (возможно даже со встроенным вочдогом).
Согласны?

Вопрос такой по теме - а при медленном нарастании питания, не сбивается ли внутренний PLL, если он был сразу запущен при старте прошивки ?

Прошивка же не запустится, пока питание не дойдет до безопасной нормы (POR не даст).

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

Не вижу необходимости во внешнем супервизоре. На небольшой конденсатор согласен хотя сам просто никуда не подключаю ногу сброса. Ну не наведется на голую двухмиллиметровую ногу такая помеха, чтобы перетягивать 40 кОм встроенной подтяжки в течении более 100 нс. А более короткие импульсы отсекаются встроенным фильтром.

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

Почитал все ответы, но прояснения пока так и не наступило...
Дополнительно к описанной ситуации есть еще такое наблюдение: если на вход питания устройства повесить большую емкость (2000 мкФ) и не вешать кондер на сброс, то в этом случае тоже все работает нормально.

Вот-вот, 2000мкФ эт перебор (по габаритам), а танталовых пару по 33..68 мкФ по питанию всегда полезно.

а при достижении к примеру +3В после запуска прошивки медленное или быстрое плавание питания в пределах нормы (+3...+3.6В) уже не помешают работе PLL ?


я как для наших АРМов от Миландра, так и от STM серий F0 F1 всегда вешал керамику 10мкф (или тантал до 22мкф) + 0.1мкф керамику на каждый вывод питания (разве что батарейное питание пропускал иногда, если места мало) и 10к+0.1мкф на reset и никогда проблем не возникало, питал от линейного стабилизатора всегда, аналог 1117 серии...

Это от чего нужно питать камень, чтобы так плавало питание? От батарейки?

Это я спрашиваю чисто из теоретических соображений, если будет просадка питания (хоть и в пределах допустимого питания) - то PLL же слетит ? Так то у меня пока проблем таких не возникало, всё что делал было не для батарейного питания (не портативные устройства), но почитав тему - возник такой вот вопрос. Вдруг кто сталкивался уже..

К примеру в наших 1986ВЕ92 есть такая проблема:
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
это так частота плавает при изменении питания в работе..
Более подробно описано ТУТ (ERRATA) страницы 24-25. Такая же проблема есть и у STM ?

От любого автономного источника питания, наличие плохого контакта не должно гробить прошивку, как и работу самого алгоритма чипа.
Входное напряжение стабилизатора, через делитель на лапу PVD, её входной ток в пределах 80мка в сторону от VDD, (не в землю!!!). Можно сказать что между VDD и лапой PVD - измерительный мост.

Последовательность:
сработал внутренний ресет - старт работы ядра чипа, по факту напряжение 1,8в.
Активируем прерывание по нарастанию PVD до напряжения нормы для внешнего стабилизатора, особо торопящиеся могут запустить инстал части периферии, потом уход в ожидание прерывания.
В прибывании PVD переключаем вектор обработки на спад, и установка нижней границы безопасного уровня напряжения внешнего стаба, перезапуск прерывания.
После ожидания внешнего прерывания - код автоматом стартует при выходе из PVD. Можно безопасно выполнять программу.
При снижении напряжения внешнего стаба ниже порогового уровня - снова срабатывает PVD. Дальше уже всё зависит от требований надёжности алгоритма. Запасённой энергии во ВНЕШНЕЙ ёмкости на входе внешнего стабилизатора - хватит на 10-500мс. При этом напряжение питания самого чипа будет стабильным. Времени хватит на завершение записи сектора флешпамяти например, или на аварийное гашение внешней периферии с сохранением всех требуемых таймингов.

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

И ещё, вешать большие ёмкости на ноги чипа - нет смысла, но на входное питание стаба - да.

а не проще ли для всего этого ставить просто внешний детектор? к примеру MAX811

BOOT0 притянут к земле через резюк 10К.
Пролейте, плиз, свет на то как подключить отладчик на всем скаку и посмотреть куда МК занесло.
У меня никак не получается - отладчик не ругается, но все переменные недоступны.

Попробуйте такую штуку: https://www.segger.com/systemview.html

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

Задействовать PVD - два smd резистора!!!

Для этого дела нужен J-LINK вроде бы, у меня его нет под руками.

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

Пролейте и вы свет но то, какой у вас отладчик и какая среда разработки.