Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: выравнивание кода
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > IAR
amiller
Пришлось срочно сделать маленькую поделку на STM32F103CBT6 (Maplemini).
Готового шаблона под этот камень у меня не было, но есть несколько рабочих проектов под STM32F105.
Скопировал проект, выбросил лишнее, заменил файлы конфигурации и стартап.
Работаю в ИАРе, одна из последних версий. Процессор стирается, шьется.
Но после выполнения первой команды улетает в HardFault.
В памяти вижу, что там, где должен лежать Reset_Handler - всегда нечетный адрес.
Вероятно в этом и есть причина такого поведения. Но как я этого добился, не могу понять.
Попытки тасовать модули в памяти не помогают, адрес меняется, но всегда нечетный.
Ничего нечётного в памяти нет, да и с чего компилятор так располагает в памяти main, совершенно не понимаю.
Может кто подскажет идею? В опциях проекта вроде уже всё просмотрел...
Непомнящий Евгений
Младший бит - это признак STUB, он и должен быть установлен
Obam
"после выполнения первой команды" чего? Стартап кода или main()?
Reset_Handler это точка входа __iar_program_start, а не точка входа в main().
amiller
Цитата(Непомнящий Евгений @ Mar 10 2017, 14:27) *
Младший бит - это признак STUB, он и должен быть установлен

Странно, а на других проектах (рабочих) адрес чётный. Смотрел в двух вариантах.


Цитата(Obam @ Mar 10 2017, 14:53) *
"после выполнения первой команды" чего? Стартап кода или main()?
Reset_Handler это точка входа __iar_program_start, а не точка входа в main().

Вероятно всё же стартап кода, но здесь трудно сказать.
Я говорил как раз про адрес Reset_Handler, т.е. тот адрес, который находится сразу за адресом стека.
Местоположение - 0x08000004.
После открытия окна отладки указатель естественно находится на main().
При любой попытке шагнуть всё зависает на выполнении кода.
После принудительной остановки отладчик обнаруживает себя уже по вектору HardFault.
Непомнящий Евгений
Цитата(amiller @ Mar 10 2017, 15:19) *
Странно, а на других проектах (рабочих) адрес чётный. Смотрел в двух вариантах.


а где вы адрес смотрите? Прямо в бинарнике?

Цитата(amiller @ Mar 10 2017, 15:19) *
После принудительной остановки отладчик обнаруживает себя уже по вектору HardFault.


Так если у вас есть отладчик - то чего мы гадаем? Считайте содержание регистров с данными об ошибке и разберите их - поймете, что не так
amiller
Цитата(Непомнящий Евгений @ Mar 10 2017, 15:20) *
а где вы адрес смотрите? Прямо в бинарнике?

На рабочих проектах только в *.hex, а в этом тестовом и в *.hex и в отладчике IAR и читал память через ST-LINK Utility.
После адреса 0х08000000 первые 4 байта адрес стека, дальше обработчик по ресету.
Порядок байт в памяти учитывал.
Obam
Цитата(amiller @ Mar 10 2017, 16:19) *
Странно, а на других проектах (рабочих) адрес чётный. Смотрел в двух вариантах.



Вероятно всё же стартап кода, но здесь трудно сказать.
Я говорил как раз про адрес Reset_Handler, т.е. тот адрес, который находится сразу за адресом стека.
Местоположение - 0x08000004.
После открытия окна отладки указатель естественно находится на main().
При любой попытке шагнуть всё зависает на выполнении кода.
После принудительной остановки отладчик обнаруживает себя уже по вектору HardFault.


Вот как раз в main() косяк, а стартап, к которому идёт обращение из 0x08000004, уже благополучно отработал.
У вас же в настройках IAR-а: Debugger->Setup->RunTo main() - птичка стоит.
amiller
Цитата(Непомнящий Евгений @ Mar 10 2017, 15:26) *
Так если у вас есть отладчик - то чего мы гадаем? Считайте содержание регистров с данными об ошибке и разберите их - поймете, что не так

А подскажите, где смотреть? Как то до сих пор всё идеально работало. А если и были вылеты, то причины были очевидными.


Цитата(amiller @ Mar 10 2017, 15:28) *
А подскажите, где смотреть? Как то до сих пор всё идеально работало. А если и были вылеты, то причины были очевидными.

Вроде как стоят следующие флаги в SCB_CFSR
Imprecise data bus error
During exception stacking
Буду разбираться чего это такое.
Непомнящий Евгений
Цитата(amiller @ Mar 10 2017, 15:28) *
А подскажите, где смотреть? Как то до сих пор всё идеально работало. А если и были вылеты, то причины были очевидными.


Есть хорошая книжка The definitive guide to the ARM Cortex-M3 / Joseph Yiu

SCB->CFSR: Confgurable Fault Status register
SCB->HFSR: Hard Fault Status register
SCB->DFSR: Debug Fault Status register
SCB->AFSR: Auxiliary Fault Status register
SCB->MMAR: MemManage Fault Address
SCB->BFAR: Bus Fault Address register

Вот оттуда пример обработчика

Код
// hard fault handler wrapper in assembly
// it extract the location of stack frame and pass it
// to handler in C as pointer.
__asm void hard_fault_handler_asm(void)
{
TST LR, #4
ITE EQ
MRSEQ R0, MSP
MRSNE R0, PSP
B __cpp(hard_fault_handler_c )
}
The second part of the handler is in C. Here, we demonstrate how the stacked register contents and the Fault Status registers can be accessed.
// hard fault handler in C,
// with stack frame location as input parameter
void hard_fault_handler_c(unsigned int * hardfault_args)
{
unsigned int stacked_r0;
unsigned int stacked_r1;
unsigned int stacked_r2;
unsigned int stacked_r3;
unsigned int stacked_r12;
unsigned int stacked_lr;
unsigned int stacked_pc;
unsigned int stacked_psr;
stacked_r0 = ((unsigned long) hardfault_args[0]);
stacked_r1 = ((unsigned long) hardfault_args[1]);
stacked_r2 = ((unsigned long) hardfault_args[2]);
stacked_r3 = ((unsigned long) hardfault_args[3]);
stacked_r12 = ((unsigned long) hardfault_args[4]);
stacked_lr = ((unsigned long) hardfault_args[5]);
stacked_pc = ((unsigned long) hardfault_args[6]);
stacked_psr = ((unsigned long) hardfault_args[7]);
printf ("[Hard fault handler]\n");
printf ("R0 = %x\n", stacked_r0);
printf ("R1 = %x\n", stacked_r1);
printf ("R2 = %x\n", stacked_r2);
printf ("R3 = %x\n", stacked_r3);
printf ("R12 = %x\n", stacked_r12);
printf ("LR = %x\n", stacked_lr);
printf ("PC = %x\n", stacked_pc);Cortex-M3 Troubleshooting Guide 425
printf ("PSR = %x\n", stacked_psr);
printf ("BFAR = %x\n", (*((volatile unsigned long *)(0xE000ED38))));
printf ("CFSR = %x\n", (*((volatile unsigned long *)(0xE000ED28))));
printf ("HFSR = %x\n", (*((volatile unsigned long *)(0xE000ED2C))));
printf ("DFSR = %x\n", (*((volatile unsigned long *)(0xE000ED30))));
printf ("AFSR = %x\n", (*((volatile unsigned long *)(0xE000ED3C))));
exit(0); // terminate
return;
}
amiller
Цитата(Непомнящий Евгений @ Mar 10 2017, 15:49) *
Есть хорошая книжка The definitive guide to the ARM Cortex-M3 / Joseph Yiu

SCB->CFSR: Confgurable Fault Status register
SCB->HFSR: Hard Fault Status register
SCB->DFSR: Debug Fault Status register
SCB->AFSR: Auxiliary Fault Status register
SCB->MMAR: MemManage Fault Address
SCB->BFAR: Bus Fault Address register

Ещё в двух регистрах BFAR и MMFAR находится одинаковый адрес: 0xE000EDF8. Вроде относится к области внутренней периферии кортекса, но идентифицировать адрес не смог.
Похоже ещё есть вероятность, что просто процессор дохлый, или спалили статикой при пайке модуля. У него ноги выведены прямо с платы на разъём.
Это если с адресом вектора всё нормально...
novikovfb
Цитата(amiller @ Mar 10 2017, 17:05) *
Похоже ещё есть вероятность, что просто процессор дохлый, или спалили статикой при пайке модуля. У него ноги выведены прямо с платы на разъём.

дохлый процессор или не будет стартовать вообще (нечему стартовать) или будет получать неправильную информацию с внешних выводов, что при корректно написанной программе не должно приводить к сбоям и HardFault (может зависнуть на ожидании готовности, получить некорректную посылку из одних "0" или "1" и т.п., но не вылетать по недопустимому коду команды или передаче управления на несуществующий адрес). Битый статикой драйвер ввода/вывода на ядро влиять не должен.
amiller
Цитата(novikovfb @ Mar 10 2017, 16:23) *
дохлый процессор или не будет стартовать вообще (нечему стартовать) или будет получать неправильную информацию с внешних выводов, что при корректно написанной программе не должно приводить к сбоям и HardFault (может зависнуть на ожидании готовности, получить некорректную посылку из одних "0" или "1" и т.п., но не вылетать по недопустимому коду команды или передаче управления на несуществующий адрес). Битый статикой драйвер ввода/вывода на ядро влиять не должен.

Да это я уже так, версии кидаю.
Похоже дело всё же где то в коде. Выбросил из проекта все файлы, кроме того, где main(), и процессор задышал, стал в отладчике адекватно шагать по командам.
Сейчас по очереди подключаю файлы с различным функционалом и пока всё работает.
Я сам заинтригован, как найду причину, отпишусь. Версия с нечетным адресом не прокатила. Адрес по прежнему нечетный, но код работает. Видимо здесь выравнивание не обязательно.

Obam
Цитата(amiller @ Mar 10 2017, 17:39) *
Адрес по прежнему нечетный, но код работает. Видимо здесь выравнивание не обязательно.

Адрес чётный, а младший бит в PC == 1 - признак набора команд Tumb2, поскольку кортекс-М другую не умеет. И выравнивание обязательно, только это компилятор с линкером автоматически организуют.
Цитата
Выбросил из проекта все файлы, кроме того, где main()

Получается, что первая команда из main() не виновата (:
amiller
Цитата(Obam @ Mar 10 2017, 16:52) *
Получается, что первая команда из main() не виновата (:

Нашел причину, извиняюсь за беспокойство.
В спешке взял другой *.icf, перепутал буковки. А в программе выделил под одну переменную оперативной памяти больше, чем есть в наличии в этом кристалле.
Итог - HardFault с симптомами, что описывал ранее.
Obam
Цитата(amiller @ Mar 10 2017, 18:06) *
Нашел причину, извиняюсь за беспокойство.
В спешке взял другой *.icf, перепутал буковки. А в программе выделил под одну переменную оперативной памяти больше, чем есть в наличии в этом кристалле.
Итог - HardFault с симптомами, что описывал ранее.

Ну чё, беги за красненьким (:
amiller
Цитата(Obam @ Mar 10 2017, 16:52) *
Адрес чётный, а младший бит в PC == 1 - признак набора команд Tumb2, поскольку кортекс-М другую не умеет. И выравнивание обязательно, только это компилятор с линкером автоматически организуют.

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