> Конечно, не будет. Во всех тестах в массив будут записаны 1-3 байта
> и они ничего не поймают, в продакшоне наконец-то в этот массив
> запишут из сети 10 байт, запись затрет канарейки и структуры планировщика
> FreeRTOS, лежащие прямо за концом стека, задача вместо паники зависнет и
> девайс ребутнется по ватчдогу.

Это всякие системные ламеры, обложивщиеся RTOS не поймают, у них "тойота" и получается. А я посмотрел на тойоту. Подумал. И теперь - даже на Cortex-M без MPU научился делать лэйаут RAM где переполнение стека хоть на байт немедленно эскалирует в HARD FAULT (нет, не MPU, его нет), который не заметить очень сложно. Ибо самый суровый эксепшн на все ядро, выбивающий все кроме NMI нафиг. И теперь мы займемся реакцией на вот это, зная что в системе Ж, ждать вачдог не обязательно.

...а еще я таки сделал обработчикам приватный стек, так что они еще и что-то сделать могут. Даже если основной стек кончился. У ARM для этого довольно клевая фича есть, отдельный стек для handlers.

...кроме того я заинструментил немного наколенный, но весьма забавный анализ worst-case рантайм потребления стека. Идея проста: заполняем раму паттерном в startup, пускаем фирмвару работать, если знаем самые ресурсоемкие ветки, прозваниваем их. Через некоторое время просим дамп оперативы, смотрим на регион стека, делаем выводы о runtime margins.