SimpleSoft 0 25 июля, 2019 Опубликовано 25 июля, 2019 (изменено) · Жалоба Добрый день. Свежий проект, cгенерированныйв CubeMX и собранный с помощью STM32CubeIDE падает в HardFault: размер стека в Linker script: _Min_Heap_Size = 0x2400 ; /* required amount of heap */ _Min_Stack_Size = 0x2800 ; /* required amount of stack */ место на котором срабатывает HardFault в list.c: UBaseType_t uxListRemove( ListItem_t * const pxItemToRemove ) { /* The list item knows which list it is in. Obtain the list from the list item. */ List_t * const pxList = ( List_t * ) pxItemToRemove->pvContainer; /// <--- Hardfault pxItemToRemove->pxNext->pxPrevious = pxItemToRemove->pxPrevious; pxItemToRemove->pxPrevious->pxNext = pxItemToRemove->pxNext; Может кто-то сталкивался с подобным? MCU: STM32H743XIH STM32CubeMX Ver 5.3.0 STM32CubeIDE Version: 1.0.2 FreeRTOS таймер - TIM6. Изменено 25 июля, 2019 пользователем SimpleSoft Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба Осталось дело за малым: выяснить, какое значение pxItemToRemove и откуда оно там взялось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 25 июля, 2019 Опубликовано 25 июля, 2019 · Жалоба 9 hours ago, esaulenka said: Осталось дело за малым: выяснить, какое значение pxItemToRemove и откуда оно там взялось. Я предполагал что возможно кто-то уже сталкивался. Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX. Если я генерирую в IAR ARM -> код работает нормально. Разница только в 2х файлах: Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F\port.c и portmacro.h 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 20 hours ago, SimpleSoft said: с помощью STM32CubeIDE падает в HardFault: Не увидел версию ядра МК: cortex-m0/m3/m4? Впрочем для любого возможно узнать причину HardFault, используя регистры. Прекрасные алгоритмы приведены в книгах Джозефа Ю. Это на случай, если не хочется изучать бумаги от arm.com. 5 hours ago, SimpleSoft said: Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX. Который раз твержу это, но всё-таки... зачем этот куб? Кто знает, что он там нагенерит. 20 hours ago, SimpleSoft said: MCU: STM32H743XIH Ага. не сразу заметил. Значит cortex-m7. Ну книги для него, вроде, у Дж. Ю нет. Так, что придётся обращаться к докуметации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 7 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 10 hours ago, SimpleSoft said: Я предполагал что возможно кто-то уже сталкивался. Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX. Блин. Ну что сложного-то? воткнуть в этот uxListRemove() что-то вроде if (pxItemToRemove < 0x20000000 || pxItemToRemove >= (0x20000000 + сколько-там-озу)) __BKPT(); запустить, много думать. Я, правда, с M7 не сталкивался. Это работает, если ARM оставил в M7 адреса памяти такие же, как и в остальных кортексах. Если поменяли, дополнительно придётся полистать документацию и map-файл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба Ещё можно MPU задействовать. Есть оно у M7? Тут только нюанс: если куб с ним не умеет работать, то придётся ручками инициализировать. Либо взять FreeRTOS+MPU. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 26 июля, 2019 Опубликовано 26 июля, 2019 (изменено) · Жалоба Спасибо за советы. 1 hour ago, esaulenka said: Блин. Ну что сложного-то? Ничего сложного. Я не хочу возиться с чужим кодом и всего. Если кто-то сталкивался с подобной пробемой и может поделится решением - я буду благодарен. Иначе будем с разработчиками искать. Пс: я смотрю не особо народ в восторге от Куба ;) Изменено 26 июля, 2019 пользователем SimpleSoft Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 26 июля, 2019 Опубликовано 26 июля, 2019 · Жалоба 2 minutes ago, SimpleSoft said: Если кто-то сталкивался с подобной пробемой - я буду благодарен. На этой строке (+- пару строк) у меня код точно падал много раз. Только проблемы настолько разные, что, на мой взгляд, даже не имеет смысл их рассматривать. По памяти, примерно это приводило к падению: неверные размеры стеков; ошибочная конфигруация EMC (SDRAM); один процесс что-то портил другому и т.п. Ещё раз: смотрите причину HardFault. Если уж в Cortex-m4/3 всё можно расшифровать, то в M7 точно долбжно быть. 4 minutes ago, SimpleSoft said: Пс: я смотрю не особо народ в восторге от Куба ;) Не буду говорить за всех, но я в восторге либо от своего кода, либо от проверенного миллионами (lwip, FreeRTOS), либо от коммерческих веток с обрезанием функционала (отказоустойчивая ФС Reliance Edge). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 27 июля, 2019 Опубликовано 27 июля, 2019 · Жалоба Проблему решили. const osThreadAttr_t defaultTask_attributes = { .name = "defaultTask", .priority = (osPriority_t) osPriorityNormal, .stack_size = 128 }; значение .stack_size увеличили в 2 раза - поток стал работать без сбоев 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 27 июля, 2019 Опубликовано 27 июля, 2019 · Жалоба 7 minutes ago, SimpleSoft said: значение .stack_size увеличили в 2 раза - поток стал работать без сбоев А у вас ловушка переполнения стека была включена? И если да, то какого уровня? Она, конечно, не всегда срабатывает при переполнении стэка, но иногда довольно хорошо помогает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 27 июля, 2019 Опубликовано 27 июля, 2019 (изменено) · Жалоба Да, действительно ловушка не была включена. Однако при её включении ситуация не поменялась. Попробовал configCHECK_FOR_STACK_OVERFLOW с опциями 1 и 2. FaultAnalyzer все еще ссылается на list.c файл - в тоже место. Stack вызовов выглядит так: Ветку в принципе можно закрывать. Единственное что меня смущает - так это код 1-в-1 кроме FreeRTOS portable исходников, и такое поведение. Я списываю пока это на разные компиляторы ARM IAR vs GCC ARM. Изменено 27 июля, 2019 пользователем SimpleSoft Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 27 июля, 2019 Опубликовано 27 июля, 2019 · Жалоба 1 hour ago, SimpleSoft said: Однако при её включении ситуация не поменялась. Это нормально. Однако лучше держать её включенной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 27 июля, 2019 Опубликовано 27 июля, 2019 · Жалоба 30 minutes ago, haker_fox said: Это нормально. Однако лучше держать её включенной. Спасибо за информацию. Я так понимаю для Release лучше выключить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
haker_fox 61 27 июля, 2019 Опубликовано 27 июля, 2019 · Жалоба 58 minutes ago, SimpleSoft said: Я так понимаю для Release лучше выключить? Я в релизных проектах оставляю контроль стека, а также все configASSERT и вообще всю отладочнцю систему (в том числе и самодельную: журналы и т.п.). Это значительно упрощает поиск неисправности на объекте, или по рекламации клиента. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SimpleSoft 0 27 июля, 2019 Опубликовано 27 июля, 2019 (изменено) · Жалоба Подскажите, как вы делаете подготовку к релизу? Есть ли unit test'ы? Код ревью? Функциональное тестирование? Тесты на стабильность? Изменено 27 июля, 2019 пользователем SimpleSoft Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться