Я же сразу сказал про внешнюю 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.