Камешек STM32F103C8T6. Собираю проект с нуля в Keil5. Структуры проекта собрана. Подключены файлы CMSIS библиотеки. Добавлен Startup для данной модели. Пути к инклудам прописаны. Настройки компилятора, линкера в "Options for Target..." и прочего- аналогичны тем, что в проектах, созданных Кубом. Оптимизация отключена. Тактирование, проты ввода-вывода, прерывания-все как положено... Все собирается без ошибок и заливается в МК. Код, написанный в Main-е работает (светодиодом управляю, кнопки читаю и т.п.). Во только не работают обработчики прерываний! Пробовал писать их и в main.c, и в отдельном файле.
Если запускаю кубовский проект в отладку, точка выполнения встает в начало функции Main(), что логично. А вот в новом- точка выполнения застревает где-то в ассемблеровском startup-е, на строке "LDR R0, =SystemInit". Затем наблюдаются необъяснимые чудеса. Если в запущенном режиме Debug запустить выполнение кода (F5)- обработчики начинают жить (я для простоты сделал моргание светодиодом на борту платы по прерыванию таймера1). Отключаю режим отладки, жму Reset- все затыкается и не работает. Платы пробовал разные- bluepill, STM323 Smart.
Причем есть пара проектов собранных ранее с нуля- там прерывания чудесным образом работают (хотя раньше не работали и не понятно, по какому тычку они завелись). Все библиотеки в них- одни и те же, стартап тот же.
Очень хотелось бы найти эту загадочную настройку, из за которой то работает то нет, ведь с Кубовскими проектами таких чудес не возникает.
Вопросов к вам собственно два: 1. Что является ИСТОЧНИКОМ прерываний? 2. Вы ничего не сказали о РАЗРЕШЕНИЯХ конкретных векторов в NVIC. Приведите код который формирует условия генерации прерываний и собственно сами обработчики. Весь код приводить не надо.
Причем есть пара проектов собранных ранее с нуля- там прерывания чудесным образом работают (хотя раньше не работали и не понятно, по какому тычку они завелись). Все библиотеки в них- одни и те же, стартап тот же.
Берешь и сравниваешь текстовые файлы с конфигами из рабочего и нерабочего проекта, сам так пару раз делал...
Неплохо привести код мэйна связанный с вызовом инициализации таймера. Ну и в инициализации куртуазно запускать таймер ПОСЛЕ того, как он инициализирован. Это я к тому, что TIM1->CR1=TIM_CR1_CEN; // Режим работы таймера никакой не режим, а тупо его запуск. ЗЫ. Ну и отладчик на этот случай есть. Останавливаете его и смотрите что с таймером и флагами.
RCC->CFGR |= (0x02<<RCC_CFGR_SW_Pos); // Переключаемся на работу от PLL // Ждем окончания переключения: while ((RCC->CFGR & RCC_CFGR_SWS_Msk)!=(0x02<<RCC_CFGR_SWS_Pos)){} RCC->CR &= ~(1<<RCC_CR_HSION_Pos); // Отключаем HSI }
Кстати, да. На словах в проекте Main.c, а на картинке main.cpp, для плюсов нужно обработчикам прерываний extern "C" добавлять, за исключением случаев когда стартап тоже на плюсах.
Я имею ввиду что если запустить программу кнопкой Run, находясь в отладчике, то в прерывания заходить будет. Этот проект с плюсами (экспериментировал), но пробовал и с простым Си, то же самое. В плане Си или плюсов- я экспериментировал с Кубовскими проектами- менял main.c на main.cpp, stm32f1xx_it.c на stm32f1xx_it.cpp, и все работало как часы. Прямо из обработчика прерывания по таймеру вызывался метод класса без проблем.
Тоже было подозрение, но пробовал на двух платах: самая обычная BluePill китайская за 200р и чуть подороже STM32 Smart. У обеих STM32F103С8T6 на борту. Схема.. так кроме питания 5В и собственно программатора ничего и не подключаю. У таблетки копеечный программатор-свисток, у Smart- ST-Link/V2. И там и там картина одна. И вопрос то остаётся- почему Кубовские проекты встают без всяких косяков, и работают без сбоев. Есть подозрения на сам Кейл, что он в памяти саму программу как-то криво размещает. Вот я и подумал, что может какую-то конфигу не делаю, адресацию где-нибудь не задаю и т.п. Но окно "Options for Target..." излажено вдоль и поперек, и каких-либо отличий не нашел
Нашел странную закономерность- все вышеуказанные косяки проявляются при отключенной оптимизации (О0). Если включить любой уровень О1, О3 и т.п. - все работает и в отладке и непосредственно на МК. Проверил на разных компах и разных кристаллах Глюк Кейла?
Дайте периферии хоть пару тактов после включения, перед тем как заполнять ее регистры. Например, вынестите включение всей периферии вперед, а регистры начните заполнять с той, какую включили первой. ... не внимательно посмотрел, кажется дело не в этом.
... где-то в ассемблеровском startup-е, на строке "LDR R0, =SystemInit"..." это обращение в system_stm32f10x.c - делает примерно тоже ч то вы в СистемКлок
Заголовок сообщения: Re: KEIL. Нулевой проект- на работают прерывания.
Добавлено: Ср янв 12, 2022 20:44:07
Открыл глаза
Зарегистрирован: Вс мар 21, 2021 11:06:04 Сообщений: 41
Рейтинг сообщения:0
Николай Relsart писал(а):
А вот в новом- точка выполнения застревает где-то в ассемблеровском startup-е, на строке "LDR R0, =SystemInit".
Наверное, затык возникает позже, уже после входа в SystemInit. Поставьте точку останова внутри функции SystemInit и пройдите её по-шагам, чтобы понять, где именно в ней происходит затык (скорее всего это событие HardFault). Кстати, поставьте точку останова внутри HardFaultHandler, чтобы убедиться (или наоборот), что в момент зависания вашей программы МК заходит туда. А там можно и по регистру отказов посмотреть причину.
у меня отладчик проваливается на СистемИнит в файл system_stm32f10x.c и ждет пинка на первой его процедуре. А унего в стартапе останавливается. Startupповский файл у меня на _md_vl.s заканчивается
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 14
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения