klen 1 4 февраля, 2010 Опубликовано 4 февраля, 2010 (изменено) · Жалоба Здравствуйте. работает программа на stm32f107 uIP+DHCP+HTTPD+TELNETD. все просто замечательно работает, но не долго - минуту, через примерно одинаковый интервал времени - systick показывает очень близкие значения, все вываливается в HardFaultException с вероятностью 1. видимо гдето чето кончаетсо, буфер например. пытаюсь понять. как высчитать в обработчике адрес с которого все это прилитело? нагугленная конструкция asm volatile ("MRS R0,PSP") ; asm volatile ("LDR R1,[R0,#24] \n"); выдает чето мне непонятное. спасибо. Изменено 21 ноября, 2022 пользователем haker_fox Добавил теги. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 4 февраля, 2010 Опубликовано 4 февраля, 2010 · Жалоба проблему я пофиксил - SNTP клиент косячил. все прекрасно заработато. но вопрос то отался - как в обработчике исключительной ситуации Hard Fault получить адрес инструкции котороая привела к эксепшену? Ну вопрос то наверно простой, гдето ячето неправильно даташит понимаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба Вот так у меня сработало: void hard_fault_handler(unsigned int * hardfault_args) { rs_puts("\r\nhard_fault_handler!\r\nPC="); rs_put_hex(hardfault_args[6]); for(;;); } void HardFault_Handler(void) __attribute__ (( naked )); // собственно обработчик void HardFault_Handler(void) { asm volatile ( "TST LR, #4 \n" "ITE EQ \n" "MRSEQ R0, MSP \n" "MRSNE R0, PSP \n" "B hard_fault_handler " ); } //Проверка: void test1() { __asm volatile ( "MOVS r0, #1 \n" "LDM r0,{r1-r2} \n" "BX LR \n" ); } Вывод в UART почему-то не сработал, но в отладчике видно, что в hardfault_args[6] - адрес строчки ldmia.w r0, {r1, r2}. Взято отсюда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба очень хорошо будем смотреть в "бубен около костра" только с ходу вроде бы то что я вставлял asm volatile ("MRS R0,PSP") ; asm volatile ("LDR R1,[R0,#24]"); почти тоже самое? что Вы привели, - выдавало в r1 бред. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба только с ходу вроде бы то что я вставлял asm volatile ("MRS R0,PSP") ; asm volatile ("LDR R1,[R0,#24]"); почти тоже самое? что Вы привели, - выдавало в r1 бред. Почти:) Во-первых, там идёт выбор между PSP и MSP. Может не угадали. И, во-вторых (я забыл это указать), используется naked HardFault_Handler - чтоб не портить указатель стека. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
klen 1 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба :yeah: уря уря уря!!! naked действительно во вторых!! потому что во первых я тупой - не обратилвнимание на то что стек пересчитывается...... все остально включая асм - ничего ценного, к вопросу топика ценны тока "во первых" и "во вторых" в моей нумерации. спасибо. я б еще наверно долго тупил бы и искал проблему совершенно в другом месте. ну вот, еще одно подтверждление того что простые загадки имеюют простые решения но очень сложный "этого решения" процесс Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 25 февраля, 2014 Опубликовано 25 февраля, 2014 · Жалоба Выпадаю в Hard Fault Exception. описал обработчик, получил вывод [Hard fault handler] R0 = 0x200014a0 R1 = 0x20001498 R2 = 0x2000123c R3 = 0x20001980 R12 = 0x10003 LR = 0x8002c09 PC = 0x20001498 PSR = 0x8000000f 1)как понять от куда ноги растут у проблемы? Подозреваю что не хватает кучи. при увеличении кучи в HF не попадаю. но может есть утечка, и увеличив кучу я просто оттянул конец. LR = 0x8002c09 - по этому адресу в дизассемблере нет команды. есть команда по адресу 0x8002c08: 0x2800 CMP R0,#0 PC = 0x20001498 это похоже куча, из мэпа "P2", part 3 of 3: 0x6d8 HEAP 0x20001480 0x300 <Block> HEAP uninit 0x20001480 0x300 <Block tail> CSTACK 0x20001780 0x200 <Block> CSTACK uninit 0x20001780 0x200 <Block tail> .noinit uninit 0x20001980 0x1d8 config.o [1] - 0x20001b58 0x6d8 2)В какой документации описан регистр LR? 3)в документации на М3 "STM32F10xxx Cortex-M3 programming manual" есть описание регистра Hard fault status register (SCB_HFSR) Address offset: 0x2C Reset value: 0x0000 0000 Required privilege: Privileged The HFSR gives information about events that activate the hard fault handler. Почему среди регистров в дебаггире в EW IAR нет регистра HFSR? ps EW IAR, STM32F100C8T6 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 26 февраля, 2014 Опубликовано 26 февраля, 2014 · Жалоба Судя по LR = 0x8002c09 PC = 0x20001498 , при возникновении исключения выполнялся код в ОЗУ (0x20001498). Посмотрите команду, которая находится перед 0x8002c08, возможно дело в ней. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 26 февраля, 2014 Опубликовано 26 февраля, 2014 · Жалоба спасибо. перед 0x8002c09 такой код LDR R1, [R1] LDR R1,[R1, #0x8] BLX R1 CMP R0,#0 по адресу 0x8002c08 команда CMP R0,#0. Зметил ещё что как раз в R1 = 0x20001498 в стеке есть список классов созданный через new. от сюда и рс на кучу кажет. падает в перегруженном операторе -- if(--(*(MyClass*)p) ) { } ошибки в операторе -- нет. указатель р всегда указывает на нужное место (есди его только не портят в паралельном месте). Если увеличиваю в линкере кучу с 0х400 до 0х600, то больше HF не наблюдаю. Подозрене что не хватает кучи. Как это проверить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость MALLOY2 26 февраля, 2014 Опубликовано 26 февраля, 2014 · Жалоба Если это иар и используется его алокатор, то вам http://supp.iar.com/Support/?note=28545 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 26 февраля, 2014 Опубликовано 26 февраля, 2014 · Жалоба перед 0x8002c09 такой код LDR R1, [R1] LDR R1,[R1, #0x8] BLX R1 CMP R0,#0 Команда BLX R1 должна прыгать на код вашего перегруженного оператора, а вместо этого прыгает в ОЗУ. Да, похоже, что память портится. Как посмотреть переполнение кучи в ИАРе - не знаю, не пользуюсь им. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 26 февраля, 2014 Опубликовано 26 февраля, 2014 · Жалоба Подозрене что не хватает кучи. Как это проверить? Да вроде бы несложно. После каждого вызова new (или malloc) сравнивать выделенный адрес с ранее полученными и запоминать максимальный, а в обработчике посмотреть, что получилось. Или, если есть что-нибудь типа debug_printf (IARом не пользуюсь, поэтому не знаю) - печатать в окне дебагера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 240 27 февраля, 2014 Опубликовано 27 февраля, 2014 · Жалоба Судя по , при возникновении исключения выполнялся код в ОЗУ (0x20001498). Посмотрите команду, которая находится перед 0x8002c08, возможно дело в ней. Почему Вы решили, что в LR - адрес возврата из функции, в которой произошло исключение? Имхо - там может быть что угодно. Пример: PUSH {...,LR} ;стандартный вход в функцию, вызывающую другие функции ... BL some_func С этого места в LR - может быть, что угодно, может адрес этой инструкции, а может и что-то другое если возврат из some_func осуществлялся чем-то вроде POP {..., PC}, а не BX LR. А ещё - оптимизатор может использовать LR как обычный РОН. После улёта исполнения кода в произвольное место в ОЗУ, определить можно только адрес (PC), где произошло исключение. Об остальном - только гадать. Когда я боролся с подобной проблемой, я сделал монитор регистров CPU, повесил его на высокочастотное IRQ от таймера (такое чтобы давало >90% загрузки CPU). В ISR просто писал дамп регистров CPU (и ближайшего стека) в FIFO таких дампов в ОЗУ. При наступлении сбоя - смотрел последовательность этих дампов и определял где было последнее валидное состояние. Расстояние между такими дампами получалось всего несколько десятков команд - место сбоя ловилось довольно точно. Ну или нужен какой-то аппаратный трэйсер с запоминанием потока команд и возможностью отмотать назад. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 18 27 февраля, 2014 Опубликовано 27 февраля, 2014 · Жалоба Почему Вы решили, что в LR - адрес возврата из функции, в которой произошло исключение? Имхо - там может быть что угодно. Потому что обычно там находится адрес возврата:) И обычно компилятор использует LR именно для этих целей. Пример: PUSH {...,LR} ;стандартный вход в функцию, вызывающую другие функции ... BL some_func С этого места в LR - может быть, что угодно С этого места в LR как раз адрес возврата. Так работает инструкция BL. А ещё - оптимизатор может использовать LR как обычный РОН. Не встречал такого. Компилятор знает, что там находится адрес возврата (он сам его туда положил). Поэтому обычно старается его не трогать. Если вы встречали такое, то приведите пример. После улёта исполнения кода в произвольное место в ОЗУ, определить можно только адрес (PC), где произошло исключение. А вот это обычно как раз бесполезная инфа. Ибо в случае, когда исключение вызвано улётом в несуществующие адреса, значение этого несуществующего адреса не представляет никакого интереса. А вот откуда мы прыгнули на этот несуществующий адрес - это информация очень нужная. И эта информация как раз с хорошей вероятностью лежит в регистре LR. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 27 февраля, 2014 Опубликовано 27 февраля, 2014 · Жалоба При прерываниях адрес возврата сохраняется в стек (там его можно и найти, положение известно). А в LR заносится специальное слово EXC_RETURN (там почти одни единицы). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться