Микроконтроллеры

Хочу спросить совета. 

Имеется проект на NUC972, чип с ARM9 от Nuvoton. Работает на оценочном модуле NHS-902-1-CY-1M55 2017.8.14 4L. На плате запаян серийный МК NUC972DF62Y (не инженерный образец). Рабочая тактовая частота 300 МГц.

Имеется программа, которая чаще всего нормально работает, но на уровнях "-O3 -flto" иногда прекращает выполнение (может более 6 часов работать, потом сбойнёт в произвольный момент времени).

Некоторые исследования при возникновении сбоя показали очень нехорошие вещи.

1. факт: JTAG отрубается (не работает даже nTRST, как показано ниже, прекращается формирование тактовой частоты ядра, а JTAG работает от этой тактовой частоты а не от JTAG_CLK)

2. факт: периферия отрубается (аппаратный блок CAN не формирует подтверждение приёма пакетов, а он должен это делать даже при срабатывании точки останова в отладчике); прекращается формирование частоты тактирования периферии PCLK

3. факт: кварцевый генератор работает, 12 МГц на ножках присутствует

4. факт: частота XIN с выхода кварцевого генератора 12 МГц отсутствует: на ножке CKO настроен выход с частоты XIN / 12, при работе там естественно есть ожидаемый меандр 1 МГц, но при сбое вижу лог. "1"; далее по цепочке не работает UPLL и прочие формирователи тактовых частот для всех IP блоков

5. факт: WDT не работает, процессор не сбрасывается, потому что я настроил источник тактовой блока WDT как XIN, а т.к. XIN отсутствует, то и WDT не считает

6. факт: при сбое на ножке CKO вижу лог. "1" со стабильной частотой около 73..75 МГц и амплитудой 240..320 мВ относительно 2.72 Вольта (что намекает на аппаратный сбой в работе блока тактовой частоты при передаче сигнала от генератора на цепь XIN)

7. факт: RESET работает

Я сейчас пока не веду речь о возникновении сбоя, это могут быть баги в чипе или баги в компиляторе или баги в ПО. Как определить последовательность инструкций, приводящих к сбою -- ещё та головная боль (если вообще сбоит из-за ошибок ПО; можно искать чёрную кошку в тёмной комнате при её отсутствии).

Я не представляю себе как любой программный сбой может привести к данной ситуации. Обычно при программном сбое срабатывает data/prefetch/undefined abort, который легко ловится отладчиком и далее по известному списку.

Главное, что этот сбой возможен, и невозможно выйти из этого сбоя (без внешнего WDT и формирования ~RESET).

Кто-нибудь сталкивался с подобным?

Как можно выяснить причину проблемы?

Как можно определить последовательность инструкций, приводящих к сбою?

Лучшее решение -- отказаться от этого МК, но это невозможно (у нас несколько тыщ на складе лежит, руководство не пойдёт на это).

Альтернативное решение -- внешний WDT, сброс МК при таком сбое и добавление алгоритма восстановления прошлого рабочего состояния при таком сбое (например, хранить данные в определённой области SRAM, которая сохраняет своё состояние при формировании RESET).