ARM GCC не удается создать рабочий двоичный файл для STM32F4, много отброшенного кода
Я перенес все свои проекты STM32 в Codeblocks IDE и компилятор GCC (arm-none-eabi). Этот процесс использует CubeMX от STM для генерации базового кода, а затем объединяет все в соответствующую папку с файлом проекта кодовых блоков, .s, .ld и т. д.
Заметил, что мои проекты, использующие cortexM0, собираются и работают нормально, однако для проекта cortexM4 (STM32F401RE) при запуске встроенного исполняемого файла происходит множество диких вещей, поэтому мой вопрос здесь.
Я предполагаю, что я неправильно вызываю GCC или где-то какая-то неправильная конфигурация.
Как «определяет»
СТМ32F401xE
В качестве «Параметры компилятора»:
-mcpu=cortex-m0 (примечание: должно быть -mcpu=cortex-m4) -ffunction-разделы -fdata-разделы -fno-common -с
В качестве «Параметры компоновщика»:
-Wl,--gc-разделы -Wl,-Map,default/ggmeg.map -T ./STM32F401RETx_FLASH.ld -Wl,--print-memory-usage,-gc-sections,-relax
Любая помощь приветствуется. Спасибо,
Обратите внимание, что у меня нет живой отладки, поскольку я использую старый segger Jlink в качестве интерфейса SWD. Мой первый шаг отладки - после HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); - чтобы установить GPIO на 1, затем выполните while(1){}, чтобы я знал, что мой код выполнился до этого момента.
Теперь дикие вещи:
- При компиляции с -mcpu=cortex-m4 код вылетает, не дойдя до моей точки.
- Компилировать с -mcpu=cortex-m0 (примечание: я использую STM32 — M4), работает лучше, но...
- Если я установлю GPIO на 1 в конце и внутри MX_GPIO_Init(); GPIO установлен на 1, отлично.
- Если я установлю GPIO на 1 после MX_GPIO_Init(); он вылетает, не дойдя до моего раздела.
Мой вывод таков: MX_GPIO_Init(); происходит сбой по возвращении, что указывает на серьезную проблему.
В качестве совета - придерживайтесь smcubeide.
Устанавливаете ли вы действительный начальный указатель стека по смещению 0x0 в своем изображении?
@pmacfarlane Спасибо, у меня 0x00800120 по адресу 0x0. Имеет ли это смысл? Я сравнивал с другими постройками/проектами, и эта ценность каждый раз сильно различалась.
@0___________ Хорошо, спасибо. Это цель моей миграции — уйти от этой IDE. -mthumb должен уменьшить размер кода, но это не должно иметь никакого отношения к сбою, верно. Я получаю такое же поведение.
Я компилирую с помощью gcc и cmake, и у меня нет никаких проблем.
@ggadde29 0x00800120 не выглядит хорошим начальным указателем стека. Я не думаю, что этот адрес вообще есть в SRAM.
@pmacfarlane кажется правильным, потому что порядок байтов меняется. Перед сбоем выполняется довольно много кода HAL, поэтому я сомневаюсь, что проблема в этом. Также я пересобрал код проекта, используя STM32L412R8, который также является ядром M4. Возникает та же проблема: сгенерированный код GCC дает сбой в случайных точках. Другая плата, другой MCU.
Дополнительное расследование: похоже, что системный контроллер зависает в STM32F4 и STM32L4 при использовании последней версии CubeMX для генерации кода для GCC. Это объясняет, почему код ведет себя хаотично. Вернусь, когда/если будет найдена причина.
Ответы 1
После проб и ошибок с флагами GCC проблема была обнаружена:
-mcpu=cortex-m4 также необходимо передать компоновщику (как компилятору, так и компоновщику).
При компиляции кода CubeMX для STM32F4 или STM32L4 с флагом -mcpu=cortex-m0. Библиотека CubeMX дает сбой в основных моментах, включая неспособность инициализировать PLL, и программа будет работать на частоте 4 МГц (скорость загрузчика). Поэтому систик работал - в нашем случае - в 20 раз медленнее, создавая ложное впечатление, что программа аварийно завершилась (это не так). Причина этой проблемы неизвестна, поскольку ошибок компиляции нет, и M4 должен нормально выполнять инструкции M0.
Это влияет только на кору M4, а не на M0.
ты скучаешь -mthumb