Нужно пользоваться регистром, который показывает причину сброса. Можно совместно с ячейкой ОЗУ (и никаких случайных совпадений там уже быть не может), а можно и без неё, как отметил Сергей Борщ.

А зачем "сброс собакой"? Что, без сброса чтото изменится? В любом случае все теже самые регистры задействованы записи/чтения флаша.
Залил, проверил и прыгнул.
Тогда и уходить никуда не надо..


Случайные совпадения в ОЗУ могут быть всегда.

Как страшно жыть... Так никакая программа работать не сможет :-)
Случайные совпадения в моей схеме исключены. Вы просто не разобрались до конца.

Почему не разобрался? 2 никому не нужных движения: ресет и использование РАМ

Вам не нужны - не используйте. А я одним легким движением уверен, что у меня не продолжает молотить АЦП загаживая по DMA уже не свою память, мне не нужно затыкать таймера, генерящие прерывания с несуществующими в загрузчике обработчиками, что однократно запускаемая в LPC2xxx собака и в загрузчике и в приложении работает с разными настройками. Вы же можете все эти действия проводить вручную и на очередной версии приложения вдруг обнаружить, что не можете обновить прошивку потому что когда-то давно проектируя загрузчик, забыли заткнуть какую-то не использовавшуюся тогда периферию, а теперь, в новой версии, эта периферия мешает работать загрузчику. Пожалуйста! Каждый сам себе злобный Буратина.

А.. А я в бутлоадере не пользую АЦП и тому подобное.
Канал для записи во флеш и обмена данными - один из USB/RS232 и так далее... Все.

А! Собака! Вот оно где порылось. Вотчдог - зло, его использовать плохая привычка.
Тем более в бутлоадере. Он должен быть прост и бронебоен.
Если там нужен вотчдог, чтото не так.

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

Все же переход в загрузчик из основного приложения прыжком - реально зло... Надо в загрузчик переходить с чистого листа.
Так же и в приложение хорошо бы перейти с чистого листа, ну мало ли что... мое ИМХО

Именно. Тем более что реализуется это гораздо проще, чем все остальные пути.

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


Дык - програмный ресет, ничего не надо затыкать.
А вот перед прыжком в программу USB затыкаем.
И надо в главной программе explicitly сделать __enable_interrupt()
Все, больше телодвижений не надо.

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



Правильно. Но в приложение не обязательно

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

Зачем? Достаточно обьявить переменную как __noinit и по абсолютному адресу.

В Ф4 я через backup SRAM передаю. Для перехода из основной программы в бутлоадер и обратно.

В боотлоадер всегда по ресету, я никогда обратное не утверждал, а в главную программу просто прыжком.


Да. Подсоединять то все равно ктото должен к компьютеру.
Кстати, сегодня заказали сделать с переходом в бутлоадер по команде.
Буду в главной программе писать 0xFE в EEPROM на старте, если там 0xFF.
Перед рестартом в бутлоадер сотру на 0xFF.
Бутлоадер при 0xFF прыгать не будет.
При дисконнекте USB будет прыгать в главную.
Но человек там все равно должен быть.


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




Ух ты! Класс. Не знал про __no_init.
Да, про SRAM бакапную тоже забыл, но аксесс к ней нетривиальный тоже.


Так, что мы имеем?
STM32 имеет SRAM, то бишь статик RAM.
На триггерах, надо понимать.
Если погуглить на "sram initial state" то выпадает множество статей на тему "Initial SRAM State as a Fingerprint and Source of True Random Numbers..."
из чего можно сделать вывод, что как и следовало ожидать RAM на старте может быть в каком угодно состоянии.
На ней rely нельзя.
Буду делать через EEPROM.

ну можно же не 8 бит, а 32 бита взять, да и положить не FF - FE , а что-то позаковыристей, например название фирмы в 4 32 битных числа положить, что такое будет случайно - настолько маловероятный факт, что если произойдет будет неплохой рекламой фирмы%)

Можно. И прошивку поставить куда нибудь в пассажирский самолет.
Будет "настолько маловероятный факт", что он грохнется..

"Мы пойдем другим путем" (с)

Толстый намёк (уже третий раз в этом топике): есть регистр, показывающий причину сброса.
Совсем-совсем толсто: если сброс программный, то есть гарантия, что в нужной ячейке ОЗУ не мусор, а то, что нужно. Почему? Потому что программа записала туда то, что нужно перед тем, как вызвать программный сброс.
Народ совсем не сообразительный пошёл нынче... Я в печали :-(

Ну ваще не аргумент,...
то есть если вероятность того что 16 символов по 256 позиций на каждый сложились в правильную фразу для человека возможны (вероятность 1.1479437019748901445007192746311e-41), то где гарантия что не пролетит космической частицы, которая изменит именно этот флаг в вашем регистре... это же событие, тогда по вероятности просто каждый день происходит...

Правда та же причина не дает реально рассчитывать и на достоверную запись в ЕЕПРОМ, но к своим идеям человек относится менее критически))

Да я уже давно ответил: нет смысла ничего писать в РАМ если и так ясно что ресет программный!



Комиссии попробуйте объяснить, что "скорее всего самолет не грохнется".
2. Это бессмыслица. Если есть програмный ресет, нечего возится с РАМ.

Кстати, Су100 не на таком же принципе сделан?
Думаю что и ракета с которой спутник грохнулся, была спроектирована аналогично

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

А что, у РАМ иммунитет к космическим частицам?
Везде могут быть проблемы, нет смысла искусственно их увеличивать.

так это ваша позиция что так жить нельзя, и надо быть защищенным даже от вероятности 10^-14

У меня переход делается если во внешней flash нет новой прошивки. Возможно это сильно сложно. Зато не требует участия человека.

сильно опасно, можно сделать кирпич из прибора...

Ничего подобного. Кирпич можно сделать только при обновлении загрузчика, если он разрешён.

Мой алгоритм действий такой:
- если во внешней flash есть валидная прошивка, то сравниваем её с текущей и перешиваем если отличается. Затем запускаем основную прошивку.
- если нет новой прошивки, то сразу запускаем основную прошивку.

а... 2 флэшки...

Я же сразу сказал про внешнюю flash

Моя позиция - не стоит плодить баги без необходимости.
Все. Больше отвечать "по кругу" не буду.

Я в своём загрузчике напоролся на проблемму с SysTick. Как я не старался, мне не удалось его "полностью блокировать". Запретил глобальное прерывание, остановил SysTick, сбросил все флаги в энвике, поставил маленькую задержку и тем не менее после глобального разрешения прерывания, изредко, возникало ещё одно прерывание от SysTick. Собственно проблемму решил добавив ещё один сброс энвика с задержкой.
Я это к тому, что в каждом конкретном случае, подводные камни имеют место быть и "сбросить всё" без резета, не всегда так просто, как кажется на первый взгляд.

В NVIC можно сбросить не только разрешение прерывания, но и флаг отложенного прерывания - периферия взвела,
но в данный момент прерывание выполниться не может, т.к. запрещено. "Все не просто", но некоторые вещи вполне можно решить.

Добавлю свои 5 копеек касательно сброса периферии:

Только что напоролся на проблему в LPC1758 с UART1 с включённым аппаратным управлением потока
(в составе UART1 имеются CTS/RTS). И проявилась она именно при рестарте прошивки обычным
переходом на вектор сброса (ну естественно с выполнением всех условий по переключению режимов
thread->handler, текущего стека и пр.).
А именно: если включено управление потоком (UART1 сам формирует RTS) и FIFO заполнилось до
уровня установки RTS-стоп и в этот момент выполнить рестарт, а после рестарта идёт отключение всей
периферии с последующим включением и инициализацией, в том числе - сброс FIFO через FCR, то
после этого после включения управления потоком опять, RTS остаётся в состоянии "стоп" хотя FIFO пуст.
И никакие сбросы UART, отключения его питания в PCONP - не помогают.
Не помогает даже снижение FIFO-level до низкого уровня.
Единственный способ - отключить временно FlowControl, принять N байт в FIFO до его заполнения до
того уровня FIFO, который был ранее и только после этого опять включить - после этого начинает
работать.

А если сделать аппаратный сброс CPU (например - через WDT), то проблемы не возникает.
Похоже в составе UART есть триггер, который устанавливается при превышении заполненности
FIFO выше уровня и сбрасывается только при понижении в обратную сторону, а командами
очистки FIFO - не сбрасывается.

Ещё аналогичная проблема была у меня давно на техасском CC5502 с FIFO DMA-каналов:
при программном сбросе, если в этот момент в FIFO были данные (DMA-канал успел
выполнить чтение источника, но не успел выполнить запись), DMA-контроллер запрещается, но не
сбрасывается. И, при последующем его разрешении, при старте передачи, перед пересылаемыми данными
вылазили те застрявшие байты.
FIFO DMA-канала программно недоступна и сбросить её нельзя. Так что пришлось при старте ПО, вначале делать одну
фиктивную транзакцию (чтобы "продуть" FIFO), и только потом запускать канал в работу.

У меня то же самое было. SysTick я поборол, а вот прыжок из работающей ОС у меня так и не завёлся. То есть бут у меня работает под осью, как и основное приложение, а ось, вероятно, постоянно сидит в режиме обработчика прерывания и прыгнуть толком не может.

ОС не "сидит постоянно в режиме обработчика прерывания". Cortex-M под ОС находится или в handler- или в thread-mode.
И, если это знать, то проблем с Cortex-ядром при перезагрузке быть не должно.
У меня рестарт хоть из под ОС хоть без - работает нормально (за исключением вышеописаной проблемы с периферией). Проблемы могут быть только в периферии.

Ну вам виднее. У меня с периферией проблем не было, а у запускаемого приложения - были. Когда стал прыгать до старта оси, всё стало работать как надо.

А также с привилегированным или пользовательским уровнями thread.