Lockup (блокировка ядра Cortex-M)

Почему это происходит

Обычный отказ ведёт в обработчик с более высоким приоритетом, в крайнем случае — в HardFault с приоритетом −1. Но на приоритете −1 и выше архитектура считает любой отказ или вызов SVC фатальным: стандартный вход в исключение здесь не применяется, и большинство таких случаев приводит к lockup (ARMv7-M ARM, B1.5.15). Типичные причины:

• отказ в самом обработчике HardFault — например, он читает данные через испорченный указатель стека;
• ошибка чтения таблицы векторов при сбросе или при входе в HardFault или NMI — неверный адрес таблицы или стёртая flash;
• переход по адресу с нулевым младшим битом, но только внутри обработчика HardFault или NMI. В обычном коде такой переход даёт UsageFault INVSTATE, а при выключенном UsageFault — HardFault: DUI 0552A говорит, что выполнение команд при T = 0 ведёт «к отказу или lockup» (разд. 2.1.3, табл. 4-27); в lockup превращается только отказ, которому уже некуда эскалироваться;
• ошибка шины данных внутри HardFault или NMI при CCR.BFHFNMIGN = 0 (табл. 4-20).

Что видно снаружи

В lockup ядро многократно выбирает одну команду с фиксированного адреса: при BusFault на выборке — адрес этой команды, при ошибке чтения векторов — 0xFFFFFFFF в самом конце адресного пространства. Ядро ставит бит S_LOCKUP в регистре DHCSR и биты в регистрах отказов, соответствующие причине (B1.5.15, табл. B1-10). Почему отладчик в таком случае показывает PC = 0xFFFFFFFE, разобрано в ответе о симптомах lockup.

Выход

Архитектура допускает и самоустранение — если ошибка шины была временной, — но Arm прямо пишет, что lockup следует считать конечным состоянием, и обычно ядро остаётся в нём до сброса, например от сторожевого таймера (B1.5.15). Поэтому в готовом устройстве сторожевой таймер оставляют включённым: другого способа самостоятельно вернуться к работе у кристалла нет. Обработку отказов ядра в целом описывает статья «Cortex-M3».