Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: SAM7X. Illegal target for BX
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > ARM, 32bit
asd6715
Прошу помощи в следующем вопросе. Пишу простой код под ИАРом для SAM7X с использованием freeRTOS.
Пишу программку, которая инициализирует USART, настраивает обработчик прерываний на прием. Как только срабатывает обработчик прерываний, процессор уходит в аборт. Я проследил в отладчике за местом краха. По завершению обработчика прерывания выполняеться инструкция "BX LR". Отладчик на ней вылетает с надписью "Illegal target for BX. ARM instruction must be located on word aligned addresses" скриншот прилагаю.
Что это может быть? В чем возможная причина неработоспособности. Несколько часов воюю и никак.
dch
У Вас програмка пользовательская ? BX - это вообщето так обычно завершают отбработчик прерывания, Вам пишется что адрес перехода должен быть выровнен на четыре байта. В пользовательском контексте должно использоваться B или B<условие>
asd6715
Я пишу программу на языке Си по ИАРом. Подскажите как избавиться от этой проблеммы? Это пользовательская программа.

В старом моем проекте перед "BX LR" генерируеться ещё строка ldmia sp!,{r4,lr} и выход осуществляеться корректно. В чем это проблема? Настроек компилятора/линкера, моего кода? И как её решить? Уже что только не перепробовал не хочет поддаваться sad.gif
dch
Цитата(asd6715 @ Jul 29 2009, 01:30) *
ldmia sp!,{r4,lr}

это загрузить из стэка r4 и LR а в IAR - ключевого слова interrupt нет чтобы компилятор сохранил в стэке модифицируемые регистры , там по разному может быть реалиовано. Должно задаваться директивой начинающейся с # какие регистры сохранить или ключевым словом перед названием процедуры
aaarrr
Цитата(asd6715 @ Jul 29 2009, 00:48) *
Что это может быть? В чем возможная причина неработоспособности.

Без исходника и дизасма остается только гадать, кто там может портить LR. И крайне желательно видеть полный путь обработчика, от вектора до "падающей" процедуры.
asd6715
Эх... учиться мне ещё и учиться...
в общем во freeRTOS как я понял обработчики нужно писать вот так
Код
UsartHandler1Entry:

    portSAVE_CONTEXT        ; Save the context of the current task.

    bl    UsartHandler1            ; Call the ISR routine.

    portRESTORE_CONTEXT        ; Restore the context of the current task -
                            ; which may be different to the task that
                            ; was interrupted.
aaarrr
Цитата(asd6715 @ Jul 29 2009, 12:04) *
в общем во freeRTOS как я понял обработчики нужно писать вот так

Ну, вовсе не обязательно именно так: "обычные" обработчики тоже можно применять, если в них не вызывается YIELD_FROM_ISR().
asd6715
YIELD_FROM_ISR().А что это такое?
Я наверное не применял и оно не работало... в общем ничего страшного, главное что стало работать
aaarrr
Цитата(asd6715 @ Jul 29 2009, 12:31) *
YIELD_FROM_ISR().А что это такое?

Переключение задачи из прерывания. Например, если по результатам работы нужно переключиться на задачу с более высоким приоритетом.

Цитата(asd6715 @ Jul 29 2009, 12:31) *
Я наверное не применял и оно не работало...

Что-то мне подсказывает, что обработчик прерывания просто не был снабжен модификатором __irq.

Цитата(asd6715 @ Jul 29 2009, 12:31) *
в общем ничего страшного, главное что стало работать

Неа, главное - разобраться.
asd6715
Цитата(aaarrr @ Jul 29 2009, 11:39) *
Что-то мне подсказывает, что обработчик прерывания просто не был снабжен модификатором __irq.

Да, вы правы. Его не было, а с ним заработало. Но в любом случае я буду использовать функции изменяющие контекст задачи, поэтому нужно будет использовать те макросы. Нужно посмотреть чем отличаеться код с этим идентификатором и без него. Ещё как я понял, то что бы можно было выполнять вложенные прерывания нужно вставить инетификатор __nested


Цитата(aaarrr @ Jul 29 2009, 11:39) *
Неа, главное - разобраться.

Это и так понятно... в тех ассемблерных макросах я разобрался...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.