Редактировать : Проблема возникла из-за создания проекта Makefile, но я все еще хотел бы знать, что происходит.
Этот вопрос повторяет мою нерешенную проблему, упомянутую здесь ( Приложение STM32 иногда не запускается, остается в DFU ).
У меня есть пользовательская плата на основе STM32L486, и я использую встроенный режим DFU для загрузки новой прошивки через USB, используя dfu-util в Linux.
Иногда по неизвестным причинам приложение не запускается после выхода из режима DFU.
Небольшое изменение в коде может заставить его работать или сломать его. (см. ссылку выше для деталей).
Примеры изменений, которые могут решить проблему:
- Добавление / удаление
HAL_Delay или мигание светодиода
- + 1 или -1 для размера массива
- Добавление / удаление
sprintf формата
Кажется, что работает построение двоичного файла с оптимизацией Og (или с использованием инструмента STLink и режима отладки).
Я попытался увеличить кучу и стек (до 20 раз по умолчанию), это ничего не меняет.
Проверка подготовка мертвого кода / параметров удаления данных в Atollic, похоже, приводит к сбою сборки чаще, чем в других случаях.
Что может быть причиной того, что приложение не запускается, даже шаги инициализации?
Как я могу отследить флаги виновника, которые могут это вызвать?
Может ли это быть связано с проблемой выравнивания памяти?
Любые идеи / идеи / комментарии о том, как проверить, приветствуется.
Мне удалось воспроизвести те же проблемы (отсюда и мою другую ссылку) на плате Nucleo.
Я попытался сгенерировать Makefile проект из CubeMX, и проблема не возникает. Я предполагаю, что это ошибка в двоичном файле, сгенерированном Atollic, или в настройках компилятора / компоновщика, которые есть в IDE.
Обратите внимание, что мой Makefile использует тот же набор инструментов, что и Atollic, так что это не может быть проблемой для набора инструментов.
Настоящим эта проблема решена, но я все же хотел бы понять, что может произойти.