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

sprintf может валить прогу, если 1) аргументы не соответствуют строке формата (в частности опасно использование "%n"), 2) нижележащие функции, через которые printf (без s) печатает, вызывают ошибку, 3) если это sprintf и переполняется буфер... Что следует делать в общем случае: Во-первых должны быть включены варнинги, в частности -Wformat, -Wformat-security. Но они срабатывают только если строка формата передаётся явно, литералом, а не через другой аргумент другой функции или ещё как. В последнем случае для всех функций принимающих строку формата желательно очень добавить аттрибут __attribute__ ((format (printf, 2, 3))), где циферки поставить в зависимости от конкретного прототипа функции, тогда варнинг начнёт работать и для этой функции. Вообще я бы рекомендовал варнинги вида -Wall -Wpedantic -Wextra -Wcast-align -Weffc++ -fstrict-aliasing, и потом поотключать отдельные слишком мешающие (-Wno-xxx). Может быть, убрать -Wpedantic. Во-вторых если используется именно sprintf -- то должен быть веский повод для того, или очень чистые руки и холодная голова (когда есть 100% уверенность, что переполнения не будет, например, печатается единственное число в 32-байтный буфер). В остальных случаях следует использовать snprintf. Для обнаружения порчи стека есть у компилятора специальные опции: -fstack-protector и -fstack-protector-all. Помогают не всегда, но лучше чем ничего. Для основной массы кода первая должна быть включена. Для части кода оптимизированного по скорости можно отключить. Ещё следовало бы уметь не отлаживать всё как есть на железе, где возможности отладки минимизированы, а уметь весь код, или отдельные модули, пересобирать на ПК. Про "синтетический порт" на сахаре уже много раз писалось. И на ПК можно использовать Valgrind (Dr.Memory на windows) или Address Sanitizer (встроен в компилятор, опции -fsanitize=address и -fsanitize=undefined) для автоматического поиска ошибок. Кроме того, неплохо бы использовать какой-либо статический анализатор, хотя бы scan-build из clang-3.9. Или купить Visual Studio (Team Edition, не Professional), там тоже есть анализатор. Или PVS-Studio... Наконец test driven development. Неплохо бы делить код на мелкие модули и отлаживать их мелкими тестами. А не отлаживать разом огромную программу в которой всё.