-
- А разве так объявлять буфер можно? бомж(220 знак., 19.01.2020 14:47)
- Так можно: Nikolay_Po(161 знак., 19.01.2020 14:53)
- Вроде накопал зацепку. Что имею: Nikolay_Po(2970 знак., 19.01.2020 00:29)
- В *.map массив по-прежнему отсутствует? ЫЫукпу(154 знак., 19.01.2020 12:36)
- Нет, сейчас в *.map массив есть, его не было в моём проекте, и он влетал в исключение. Сделал тестовый пустой проект с одномерным массивом - массив есть в *.map. Nikolay_Po(157 знак., 19.01.2020 12:46)
- Как всегда, теперь, с высоты знания, все кажется очевидным. Если pop с этого места, то куда первый push был? - VLLV(19.01.2020 22:26)
- И втолкнули и вытолкнули правильно, в одно и из того же места. Просто указатель стека был инициализирован не моей программой и значением вверху ОЗУ, а бутлодером, значением глубже внутрь ОЗУ, что приводило к накладке. Nikolay_Po(90 знак., 19.01.2020 22:33)
- Да понятно уже. - VLLV(19.01.2020 22:39)
- И втолкнули и вытолкнули правильно, в одно и из того же места. Просто указатель стека был инициализирован не моей программой и значением вверху ОЗУ, а бутлодером, значением глубже внутрь ОЗУ, что приводило к накладке. Nikolay_Po(90 знак., 19.01.2020 22:33)
- соответствует ld? - Vit(19.01.2020 20:31)
- Стал соответствовать после того, как изменил уровень на BOOT0 и чип стал зеркалить на стартовый адрес нормальную флеш 0x80000000 вместо BOOT ROM с 0x1FFFB000 при "неправильном" состоянии BOOT0 на старте. - Nikolay_Po(19.01.2020 22:22)
- Просто товарищ хочет сказать "некорректное значение указателя стека". Я ему хотел сказать, что люди не так поймут, но всё время забывал... - SciFi(19.01.2020 20:59)
- Да. Мне думается, "расположение стека" и "значение указателя стека" тождественны. До тех пор, пока что-то некорректно не сменило значение указателя. Nikolay_Po(497 знак., 19.01.2020 22:26)
- Под стеком часто имеют в виду область памяти, выделенную для него (обычно от верхушки bss до верхушки ОЗУ). Ну и стек как динамическая структура данных - это содержимое ОЗУ от текущего значения указателя стека до начального значения (которое может SciFi(103 знак., 19.01.2020 22:52)
- Согласен. - Nikolay_Po(19.01.2020 23:01)
- Под стеком часто имеют в виду область памяти, выделенную для него (обычно от верхушки bss до верхушки ОЗУ). Ну и стек как динамическая структура данных - это содержимое ОЗУ от текущего значения указателя стека до начального значения (которое может SciFi(103 знак., 19.01.2020 22:52)
- Да. Мне думается, "расположение стека" и "значение указателя стека" тождественны. До тех пор, пока что-то некорректно не сменило значение указателя. Nikolay_Po(497 знак., 19.01.2020 22:26)
- Как всегда, теперь, с высоты знания, все кажется очевидным. Если pop с этого места, то куда первый push был? - VLLV(19.01.2020 22:26)
- Нет, сейчас в *.map массив есть, его не было в моём проекте, и он влетал в исключение. Сделал тестовый пустой проект с одномерным массивом - массив есть в *.map. Nikolay_Po(157 знак., 19.01.2020 12:46)
- В *.map массив по-прежнему отсутствует? ЫЫукпу(154 знак., 19.01.2020 12:36)
- я бы попробовал выровнять на 4 или даже на 8. Vit(143 знак., 18.01.2020 15:55)
- Не, у меня можно убрать только первую цифру. Остальные компилятор не даёт - жалуется, дескать, допустимо не указывать только первую размерность массива. Nikolay_Po(64 знак., 18.01.2020 16:04)
- а в тесте с одномерным? - Vit(18.01.2020 16:55)
- В тесте с одномерным тоже баг, см. ниже Nikolay_Po(124 знак., 18.01.2020 16:59)
- если записать Vit(58 знак., 18.01.2020 17:03)
- Только что проверил. Код без изменений, результат тоже. "Rough execution" из SysTick_Handler. - Nikolay_Po(18.01.2020 17:12)
- если записать Vit(58 знак., 18.01.2020 17:03)
- В тесте с одномерным тоже баг, см. ниже Nikolay_Po(124 знак., 18.01.2020 16:59)
- а в тесте с одномерным? - Vit(18.01.2020 16:55)
- Не, у меня можно убрать только первую цифру. Остальные компилятор не даёт - жалуется, дескать, допустимо не указывать только первую размерность массива. Nikolay_Po(64 знак., 18.01.2020 16:04)
- В общем, пока проблема с компилятором (или моим пониманием стандарта C) такова: Nikolay_Po(462 знак., 17.01.2020 19:59 - 20:05)
- Удалось повторить проблему в пустом проекте STM32CubeIDE. Nikolay_Po(1778 знак., 17.01.2020 21:57)
- а не может размер кучи влиять? NAUT(19.01.2020 23:51)
- Может, барьер после инкремента вставить? - Vit(18.01.2020 21:38)
- "На Count==1999 вылетает HardFault." 1) 1999(2000) - странное число. Какие есть определения с этим числом 2) может не дождавшись вылета пройтись по шагам, глядя в ассемблер? - VLLV(18.01.2020 16:47)
- Это не первая моя попытка отладить код. Разные программы отказывали на разных этапах. Какая-то на 5-м элементе, какая-то на 68-м, эта - на 1998-м (1999-й это после инкремента счётчика). Nikolay_Po(483 знак., 18.01.2020 19:40)
- ОК, варианты VLLV(197 знак., 18.01.2020 20:14)
- Камень STM32F107VCT. IAR нет и не планирую. Пробовал: Nikolay_Po(222 знак., 18.01.2020 20:51 - 21:37)
- Непонятно. Могу попробовать кусок кода в других контроллерах (CM4,CM0) на ИАРе, но есть ли такие фрагменты кода и имеет эта проверка смысл? - VLLV(18.01.2020 21:46)
- Странно всё это выглядит. Может, проблема в отладке? Разные компиляторы, разные IDE, разные программы и одна проблема - стек затирается данными, оказавшись "не в том месте". Nikolay_Po(77 знак., 18.01.2020 21:50)
- Может, не в отладке, а в прошивке? Как тут кто-то с неправильно описанным контроллером боролся. Или как в том же ИАРе так бывает - если неправильно указать прошивальщик, он неправильно заливает прошивку, соответственно потом вообще хрень VLLV(25 знак., 18.01.2020 22:13)
- Отладку отключаем и смотрим. Лампочка перестала мигать - всё плохо. - SciFi(18.01.2020 21:53)
- С этого места можно по-подробнее. Что-то не получается. Собираю "Релиз", вручную прошиваю OpenOCD файл *.elf, пробовал прошивать *.hex - шьётся, проверка ОК. Nikolay_Po(711 знак., 18.01.2020 23:20)
- Был случай, когда внезапно пропал систик, а через 2 дня внезапно появился. Так и не разобрались. - VLLV(19.01.2020 07:50)
- (HAL_GetTick() & (1u << 6)) это точно правильно ??? - Aleksey_75(18.01.2020 23:24)
- Да. Когда запускаю отладку в IDE, мигает PB12 с периодом 64мс 15 раз, на 16-м зависает. Систики, из описания функции, 1мс. - Nikolay_Po(18.01.2020 23:29)
- здесь много написали, зависает как ? в HardFault падает ? если да Aleksey_75(204 знак., 18.01.2020 23:34)
- Да писал уже не раз. Стек почему-то торчит внутри массива. И когда указатель возврата в стеке затёрт, попаду туда, куда указывает записанное в массив слово, а не туда, откуда выпал. Nikolay_Po(160 знак., 18.01.2020 23:40)
- какой начальный адрес у вашего буфера смотрели ? мож он инитится под стек? - Aleksey_75(18.01.2020 23:44)
- Начальный адрес буфера нормальный, со стеком не пересекается, см. в этом сообщении: Nikolay_Po(145 знак., 18.01.2020 23:50)
- слежу за темой, создаётся впечатление что происходит присвоение указателю стека нового значения. нужно асм ковырять. может я не прав. - m16_home(19.01.2020 00:02)
- +1. Эта мысль не даёт мне покоя. Чую, дело не в командах, а в запуске контроллера "не оттуда". Сейчас напишу под заглавным сообщением. - Nikolay_Po(19.01.2020 00:04)
- ещё. буфер DMA не налазит куда не нужно? - m16_home(19.01.2020 00:56)
- Проект пустой, шаблон STM32CubeMX, DMA не включён. - Nikolay_Po(19.01.2020 00:58)
- ээээ! указатели, как я понял вы не используете, каким образом вы херите SP? дык поставьте брекпоинт на изменение указателя стека и шагайте - Aleksey_75(19.01.2020 00:09)
- С этого момента поподробнее. В каком магазине продают такие брекпоинты? Хочу всё знать. - SciFi(19.01.2020 11:36)
- Может, watchpoint имелся ввиду? Указываешь диапазон адресов, тип операции (чтение, запись или любой) и, как только при работе контроллера, Nikolay_Po(159 знак., 19.01.2020 12:28)
- Вот-вот. Но чем чёрт не шутит, может быть, у коллеги есть секретная папочка "недокументированные возможности кортекс-м3"? - SciFi(19.01.2020 12:32)
- сорянн! чтот я затупил, такая вещь есть в LW - Aleksey_75(19.01.2020 17:50)
- Вот-вот. Но чем чёрт не шутит, может быть, у коллеги есть секретная папочка "недокументированные возможности кортекс-м3"? - SciFi(19.01.2020 12:32)
- Может, watchpoint имелся ввиду? Указываешь диапазон адресов, тип операции (чтение, запись или любой) и, как только при работе контроллера, Nikolay_Po(159 знак., 19.01.2020 12:28)
- С этого момента поподробнее. В каком магазине продают такие брекпоинты? Хочу всё знать. - SciFi(19.01.2020 11:36)
- ещё. буфер DMA не налазит куда не нужно? - m16_home(19.01.2020 00:56)
- +1. Эта мысль не даёт мне покоя. Чую, дело не в командах, а в запуске контроллера "не оттуда". Сейчас напишу под заглавным сообщением. - Nikolay_Po(19.01.2020 00:04)
- ну чудес не бывает, значит с инкрементом индекса что-то не то! слей все индексы в RTT или отладочный уарт и глянь как он себя чувствует - Aleksey_75(18.01.2020 23:53)
- слежу за темой, создаётся впечатление что происходит присвоение указателю стека нового значения. нужно асм ковырять. может я не прав. - m16_home(19.01.2020 00:02)
- Начальный адрес буфера нормальный, со стеком не пересекается, см. в этом сообщении: Nikolay_Po(145 знак., 18.01.2020 23:50)
- какой начальный адрес у вашего буфера смотрели ? мож он инитится под стек? - Aleksey_75(18.01.2020 23:44)
- Да писал уже не раз. Стек почему-то торчит внутри массива. И когда указатель возврата в стеке затёрт, попаду туда, куда указывает записанное в массив слово, а не туда, откуда выпал. Nikolay_Po(160 знак., 18.01.2020 23:40)
- здесь много написали, зависает как ? в HardFault падает ? если да Aleksey_75(204 знак., 18.01.2020 23:34)
- Да. Когда запускаю отладку в IDE, мигает PB12 с периодом 64мс 15 раз, на 16-м зависает. Систики, из описания функции, 1мс. - Nikolay_Po(18.01.2020 23:29)
- С этого места можно по-подробнее. Что-то не получается. Собираю "Релиз", вручную прошиваю OpenOCD файл *.elf, пробовал прошивать *.hex - шьётся, проверка ОК. Nikolay_Po(711 знак., 18.01.2020 23:20)
- Смысла нет. Копать надо. Я бы эту штуку с радостью поковырял, но, увы, она не здесь, а там. - SciFi(18.01.2020 21:49)
- Странно всё это выглядит. Может, проблема в отладке? Разные компиляторы, разные IDE, разные программы и одна проблема - стек затирается данными, оказавшись "не в том месте". Nikolay_Po(77 знак., 18.01.2020 21:50)
- Непонятно. Могу попробовать кусок кода в других контроллерах (CM4,CM0) на ИАРе, но есть ли такие фрагменты кода и имеет эта проверка смысл? - VLLV(18.01.2020 21:46)
- Камень STM32F107VCT. IAR нет и не планирую. Пробовал: Nikolay_Po(222 знак., 18.01.2020 20:51 - 21:37)
- ОК, варианты VLLV(197 знак., 18.01.2020 20:14)
- Это не первая моя попытка отладить код. Разные программы отказывали на разных этапах. Какая-то на 5-м элементе, какая-то на 68-м, эта - на 1998-м (1999-й это после инкремента счётчика). Nikolay_Po(483 знак., 18.01.2020 19:40)
- В симуляторе всё чики-пуки. Значит, надо вычислять точную причину, вызывающую Hard Fault. - SciFi(17.01.2020 22:53)
- Спасибо большое! Может, Errata какая... С чего начать? Nikolay_Po(119 знак., 17.01.2020 22:59)
- Самое простое: SciFi(488 знак., 17.01.2020 23:15)
- Если немного заморочиться, то можно легко найти проблему: evgeniy1294(2543 знак., 18.01.2020 00:04)
- Имеет место наезд стека на массив. См. ниже. Nikolay_Po(2952 знак., 18.01.2020 14:26 - 14:30)
- Не понял, откуда вывод про стек? И как могло скушаться 30 килобайт стека в программе, которая ничего не делает? - SciFi(18.01.2020 14:40)
- До вылета в исключение sp указывает на внутренность массива. Программа крашится из-за возврата из прерывания на неадекватный адрес, так как нормальный адрес возврата оказывается затёрт записью в массив. - Nikolay_Po(18.01.2020 14:49)
- Это можно поисследовать. Заполнить массив паттерном, как уже упоминалось, прогнать сколько-то итераций, потом посмотреть на стек и сравнить с ожиданиями. Можно watchpoint поставить на участок стека, который по идее никто не должен трогать. - SciFi(18.01.2020 14:51)
- Прошерстил массив. Паттерн есть :). Это нули после инициализации. Nikolay_Po(249 знак., 18.01.2020 15:17)
- Кстати, моя инициализация стек не обнуляет, потому что зачем. Что я делаю не так? - SciFi(18.01.2020 17:02)
- Немного не так. Паттерн был внутри массива. Массив инициализирован. Поэтому нормальный паттерн - нули. Nikolay_Po(140 знак., 18.01.2020 18:53)
- Единственный вариант - обработана команда установки указателя стека. - VLLV(18.01.2020 20:11)
- Немного не так. Паттерн был внутри массива. Массив инициализирован. Поэтому нормальный паттерн - нули. Nikolay_Po(140 знак., 18.01.2020 18:53)
- Кстати, моя инициализация стек не обнуляет, потому что зачем. Что я делаю не так? - SciFi(18.01.2020 17:02)
- Прошерстил массив. Паттерн есть :). Это нули после инициализации. Nikolay_Po(249 знак., 18.01.2020 15:17)
- Это можно поисследовать. Заполнить массив паттерном, как уже упоминалось, прогнать сколько-то итераций, потом посмотреть на стек и сравнить с ожиданиями. Можно watchpoint поставить на участок стека, который по идее никто не должен трогать. - SciFi(18.01.2020 14:51)
- До вылета в исключение sp указывает на внутренность массива. Программа крашится из-за возврата из прерывания на неадекватный адрес, так как нормальный адрес возврата оказывается затёрт записью в массив. - Nikolay_Po(18.01.2020 14:49)
- Не понял, откуда вывод про стек? И как могло скушаться 30 килобайт стека в программе, которая ничего не делает? - SciFi(18.01.2020 14:40)
- Стек превращается в месиво ещё до срабатывания исключений. Попробовал такую функцию: Nikolay_Po(2004 знак., 18.01.2020 13:55)
- Питание, помехи, убогая схема/плата? Думаю, если постараться, можно заставить проц глючить так, что отлаживать придётся до следующей пятилетки. - SciFi(18.01.2020 14:47)
- Была аналогичная проблема с буферами под eth. Решил созданием отдельной секции в скрипте линкера. Вообще надо скрипт линкера смотреть, постоянно нахожу в них косяки. - evgeniy1294(18.01.2020 14:43)
- Имеет место наезд стека на массив. См. ниже. Nikolay_Po(2952 знак., 18.01.2020 14:26 - 14:30)
- Если немного заморочиться, то можно легко найти проблему: evgeniy1294(2543 знак., 18.01.2020 00:04)
- Самое простое: SciFi(488 знак., 17.01.2020 23:15)
- Спасибо большое! Может, Errata какая... С чего начать? Nikolay_Po(119 знак., 17.01.2020 22:59)
- Например, в объявлении массива используются ADCchNum, St1BuffSize. А если эти штуки разные в разных местах? Сразу начнутся чудесатые чудеса. Это только то, что видно, а там этих мин может быть сколько угодно, в зависимости от степени шаловливости SciFi(7 знак., 17.01.2020 20:05)
- Согласен. Нарочно проверил. Заменил ADCchNum и St1BuffSize на числа 17 и 64, в том числе и в обёртке-проверке индексов. HardFault_Handler(). Nikolay_Po(152 знак., 17.01.2020 20:12)
- Удалось повторить проблему в пустом проекте STM32CubeIDE. Nikolay_Po(1778 знак., 17.01.2020 21:57)
- "запись в буфер сама затирает важные данные в ОЗУ" - с этого момента поподробнее. Что эта фраза означает? Потому что противоречие: запись в буфер, но не в буфер, а в "важные данные в ОЗУ". - SciFi(17.01.2020 19:36)
- Код файла custom_adc.c, из прерывания записывает в буфер новые данные. С точки зрения работы функции прерывания АЦП - всё нормально. Nikolay_Po(1597 знак., 17.01.2020 19:48)
- Ерунда какая-то. Танец с бубном. "по логике, оказывался в стеке" - странные фантазии. Короче, хз, что происходит, в вводных данных никакого криминала не видно. - SciFi(17.01.2020 19:56)
- Хорошо, перефразирую: Обращение к массиву из кода Си приводит к работе к области, где размещается стек, разрушая полезное содержимое стека. Nikolay_Po(436 знак., 17.01.2020 20:04)
- Откуда сведения, что ОЗУ достаточно? Может быть, стек налазит на bss в любом случае. Например, засунули массив в именованную секцию, она оказалась в более младших адресах, и стек наезжает на другие переменные, которые завалят программу чуть позже. - SciFi(17.01.2020 20:11)
- Блин, могу ли я рассчитывать на ошибку от линкера в таком случае? У меня ни малейших сомнений, что XC16 Микрочипа такое отловил и не дал бы выстрелить в ногу. Nikolay_Po(216 знак., 17.01.2020 20:15)
- Стек надо проверять самостоятельно. Например, заполнить его какой-нибудь ерундой типа 0xDEADBEEF на старте, а через некоторое время проверять хотя бы просмотром памяти в отладчике. - SciFi(17.01.2020 20:18)
- Ерунда какая-то. Похоже, меня Microchip XC16 избаловал. Не могу поверить просто, что программисту Си: "Стек надо проверять самостоятельно". Nikolay_Po(227 знак., 17.01.2020 20:23)
- Пока найден баг в программе. Вернее, найден факт его наличия. Вроде бы gcc что-то умеет в части вычисления использования стека. Но в типичной программе много непредсказуемого. Те же обработчики прерываний - их хвалёный мелкочип учитывает? Им же SciFi(17 знак., 17.01.2020 20:35)
- Конечно Microchip XC16 учитывает, в том числе и обработчики прерываний. Предположение, что GCC не учитывает глубину стека для прерываний, по мне, такая же дикость. Nikolay_Po(644 знак., 17.01.2020 20:51)
- Я не в курсе, XC16 - это пики же? Там, наверное, в процессоре есть регистр, который отлавливает переполнение стека? Ну так в кортексе этого нет, и звените. И почему вы решили, что "глобальная волатильная переменная размещается? GCC в стеке? (не в SciFi(253 знак., 17.01.2020 21:02)
- Да, пики. Есть. Но он не срабатывает! Компилятор до этого не доводит. Не думал, что всё ТАК запущено у GCC-водов. Nikolay_Po(63 знак., 17.01.2020 21:14)
- Ушло куда-то в сторону. Не факт, что у вас стек переполняется. Это было предположение, в итоге получилось бурление не совсем в тему :-) - SciFi(17.01.2020 21:26)
- Не, ну с индексами, с указателями можно было с XC16 накосячить. Nikolay_Po(127 знак., 17.01.2020 22:54)
- Ушло куда-то в сторону. Не факт, что у вас стек переполняется. Это было предположение, в итоге получилось бурление не совсем в тему :-) - SciFi(17.01.2020 21:26)
- Да, пики. Есть. Но он не срабатывает! Компилятор до этого не доводит. Не думал, что всё ТАК запущено у GCC-водов. Nikolay_Po(63 знак., 17.01.2020 21:14)
- Я не в курсе, XC16 - это пики же? Там, наверное, в процессоре есть регистр, который отлавливает переполнение стека? Ну так в кортексе этого нет, и звените. И почему вы решили, что "глобальная волатильная переменная размещается? GCC в стеке? (не в SciFi(253 знак., 17.01.2020 21:02)
- Конечно Microchip XC16 учитывает, в том числе и обработчики прерываний. Предположение, что GCC не учитывает глубину стека для прерываний, по мне, такая же дикость. Nikolay_Po(644 знак., 17.01.2020 20:51)
- Пока найден баг в программе. Вернее, найден факт его наличия. Вроде бы gcc что-то умеет в части вычисления использования стека. Но в типичной программе много непредсказуемого. Те же обработчики прерываний - их хвалёный мелкочип учитывает? Им же SciFi(17 знак., 17.01.2020 20:35)
- что характерно, контроллировать единственный байт нельзя, ибо он может попасть на не используемую в этой ветке кода переменную - lloyd(17.01.2020 20:20)
- Ерунда какая-то. Похоже, меня Microchip XC16 избаловал. Не могу поверить просто, что программисту Си: "Стек надо проверять самостоятельно". Nikolay_Po(227 знак., 17.01.2020 20:23)
- Стек надо проверять самостоятельно. Например, заполнить его какой-нибудь ерундой типа 0xDEADBEEF на старте, а через некоторое время проверять хотя бы просмотром памяти в отладчике. - SciFi(17.01.2020 20:18)
- Блин, могу ли я рассчитывать на ошибку от линкера в таком случае? У меня ни малейших сомнений, что XC16 Микрочипа такое отловил и не дал бы выстрелить в ногу. Nikolay_Po(216 знак., 17.01.2020 20:15)
- Откуда сведения, что ОЗУ достаточно? Может быть, стек налазит на bss в любом случае. Например, засунули массив в именованную секцию, она оказалась в более младших адресах, и стек наезжает на другие переменные, которые завалят программу чуть позже. - SciFi(17.01.2020 20:11)
- Хорошо, перефразирую: Обращение к массиву из кода Си приводит к работе к области, где размещается стек, разрушая полезное содержимое стека. Nikolay_Po(436 знак., 17.01.2020 20:04)
- Ерунда какая-то. Танец с бубном. "по логике, оказывался в стеке" - странные фантазии. Короче, хз, что происходит, в вводных данных никакого криминала не видно. - SciFi(17.01.2020 19:56)
- Код файла custom_adc.c, из прерывания записывает в буфер новые данные. С точки зрения работы функции прерывания АЦП - всё нормально. Nikolay_Po(1597 знак., 17.01.2020 19:48)
- А разве так объявлять буфер можно? бомж(220 знак., 19.01.2020 14:47)