Тестирование кода.

Итак... Я бы не стал полагаться на один только отладчик, не важно чей он: IAR, Keil, GDB. Следует воспользоваться в одну из первых очередей теми аппаратными средствами отладки, которые предоставляет ваш микроконтроллер. Вы не указали, какой у вас. Рискну предположить, что Cortex-mx, т.к. они довольно популярны. Если я угадал, то используйте их мощный вектор прерывания HardFault. Особенно много информации он предоставляет у M3/M4 версии МК. В M0 там возможности довольно скромны. С помощью грамотно написанного обработчика (см. офицальный сайт arm.com или книги Джозефа Ю) можно понять причину сбоя МК, например, было обращение к несуществующей памяти, либо к невыровненному адресу (для m0 актуально всегда, для m3/m4 можно включить по желаюнию). Также следует ввести журнал ошибок, который в случае проблемы сохраняет минимум данных (содержимое ргистров, стека, строку/имя файла) в какую-либо энергонезависимую память. Это помогает отладить устройство, которое вроде-бы и работает, но периодически сбоит. Особенно, если это объект, например подстанция или завод. Конечно, следут дополнительно пользоваться статическими анализаторами кода. Например этим. В IAR среде есть свой статический анализатор, ловушки переполнения стека, отладчик "онлайн" C-RUN. Не знакю, как с этим в Кейл, нужно читать доку, но если подобные средства имеются, их следует исопльзовать. По-крайней мере статический анализатор. Запускается очень просто, а ошибки коварные в тексте отлавливает на ура. Мы сейчас планируем внедрить юнит-тестирование у себя на фирме. Пока всё это в процессе, тут ничего не подскажу. Но говорят, что тоже отлично помогает. Есть ещё аппаратные фишечки микроконтроллеров на базе ядра Cortex, как ETM. Это аппаратный буфер, который хранит N команд выполненных перед сбоем. Его можно просматривать через JTAG-отладчик. Но это если у вас кортекс.

Также на форуме поищите темы по отладке кода, в т.ч. мою годичной или чуть более давности. Кстати, вот она.