[Terminator 0]

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

[A. Fig Lee 0]

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

Моя позиция - не стоит плодить баги без необходимости.

Все. Больше отвечать "по кругу" не буду.

[vlad_new 1]

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

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

[adnega 10]

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

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

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

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

[jcxz 184]

Добавлю свои 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), и только потом запускать канал в работу.

[andrewlekar 0]

Я в своём загрузчике напоролся на проблемму с SysTick. Как я не старался, мне не удалось его "полностью блокировать".

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

[jcxz 184]

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

ОС не "сидит постоянно в режиме обработчика прерывания". Cortex-M под ОС находится или в handler- или в thread-mode.

И, если это знать, то проблем с Cortex-ядром при перезагрузке быть не должно.

У меня рестарт хоть из под ОС хоть без - работает нормально (за исключением вышеописаной проблемы с периферией). Проблемы могут быть только в периферии.

[andrewlekar 0]

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

[ViKo 1]

ОС не "сидит постоянно в режиме обработчика прерывания". Cortex-M под ОС находится или в handler- или в thread-mode.

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

[Mysteo 0]

Потрите пожалуйста сообщение, не в той теме отписался