получается стартап разный после подачи питания и после 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/.
Возможно там собака порылась

Сообщение отредактировал pistoletov - May 5 2015, 08:31

Здравствуйте, все! Кажется, у меня есть решение этой проблемы. Битый час возюкался с ней. Все перепробовал. Я не вполне уверен, что так везде, но у меня стал запускаться после подачи питания тогда, когда 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).

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

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