Перейти к содержанию
    

STM32CubeIDE: Сгенерированный FreeRTOS проект в Cube падает в HardFault

Добрый день.

Свежий проект, cгенерированныйв CubeMX и собранный с помощью STM32CubeIDE падает в HardFault:

image.png.2329db47755f7c9d4d584c7c0ab2ea91.png

размер стека в 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.

Изменено пользователем SimpleSoft

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Осталось дело за малым: выяснить, какое значение pxItemToRemove и откуда оно там взялось.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 hours ago, esaulenka said:

Осталось дело за малым: выяснить, какое значение pxItemToRemove и откуда оно там взялось.

Я предполагал что возможно кто-то уже сталкивался.  Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX.

Если я генерирую в IAR ARM -> код работает нормально.

Разница только в 2х файлах:

Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM4F\port.c и portmacro.h

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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. Ну книги для него, вроде, у Дж. Ю нет. Так, что придётся обращаться к докуметации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

10 hours ago, SimpleSoft said:

Я предполагал что возможно кто-то уже сталкивался.  Не хотелось бы копаться в "свежем" коде который сгенерирован CubeMX.

Блин. Ну что сложного-то?

воткнуть в этот uxListRemove() что-то вроде

if (pxItemToRemove  < 0x20000000 || pxItemToRemove  >= (0x20000000 + сколько-там-озу))

__BKPT();

запустить, много думать.

 

Я, правда, с M7 не сталкивался. Это работает, если ARM оставил в M7 адреса памяти такие же, как и в остальных кортексах. Если поменяли, дополнительно придётся полистать документацию и map-файл.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ещё можно MPU задействовать. Есть оно у M7? Тут только нюанс: если куб с ним не умеет работать, то придётся ручками инициализировать. Либо взять FreeRTOS+MPU.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо за советы. 

1 hour ago, esaulenka said:

Блин. Ну что сложного-то?

Ничего сложного. 

Я не хочу возиться с чужим кодом и всего.

Если кто-то сталкивался с подобной пробемой и может поделится решением - я буду благодарен.

Иначе будем с разработчиками искать. 

Пс: я смотрю не особо народ в восторге от Куба ;) 

Изменено пользователем SimpleSoft

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, SimpleSoft said:

Если кто-то сталкивался с подобной пробемой - я буду благодарен.

На этой строке (+- пару строк) у меня код точно падал много раз. Только проблемы настолько разные, что, на мой взгляд, даже не имеет смысл их рассматривать. По памяти, примерно это приводило к падению: неверные размеры стеков; ошибочная конфигруация EMC (SDRAM); один процесс что-то портил другому и т.п. Ещё раз: смотрите причину HardFault. Если уж в Cortex-m4/3 всё можно расшифровать, то в M7 точно долбжно быть.

4 minutes ago, SimpleSoft said:

Пс: я смотрю не особо народ в восторге от Куба ;) 

Не буду говорить за всех, но я в восторге либо от своего кода, либо от проверенного миллионами (lwip, FreeRTOS), либо от коммерческих веток с обрезанием функционала (отказоустойчивая ФС Reliance Edge).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Проблему решили.

  const osThreadAttr_t defaultTask_attributes = {
    .name = "defaultTask",
    .priority = (osPriority_t) osPriorityNormal,
    .stack_size = 128
  };

значение .stack_size увеличили в 2 раза - поток стал работать без сбоев

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 minutes ago, SimpleSoft said:

значение .stack_size увеличили в 2 раза - поток стал работать без сбоев

А у вас ловушка переполнения стека была включена? И если да, то какого уровня? Она, конечно, не всегда срабатывает при переполнении стэка, но иногда довольно хорошо помогает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да, действительно ловушка не была включена. Однако при её включении ситуация не поменялась.

Попробовал configCHECK_FOR_STACK_OVERFLOW с опциями 1 и 2.

FaultAnalyzer все еще ссылается на list.c файл - в тоже место.

Stack вызовов выглядит так:

image.png.8d1f9b4405ea19c15fc9d50e1491d405.png

Ветку в принципе можно закрывать.

Единственное что меня смущает - так это код 1-в-1 кроме FreeRTOS portable исходников, и такое поведение. Я списываю пока это на разные компиляторы ARM IAR vs GCC ARM.

Изменено пользователем SimpleSoft

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, SimpleSoft said:

Однако при её включении ситуация не поменялась.

Это нормально. Однако лучше держать её включенной.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

30 minutes ago, haker_fox said:

Это нормально. Однако лучше держать её включенной.

Спасибо за информацию. Я так понимаю для Release лучше выключить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

58 minutes ago, SimpleSoft said:

Я так понимаю для Release лучше выключить?

Я в релизных проектах оставляю контроль стека, а также все configASSERT и вообще всю отладочнцю систему (в том числе и самодельную: журналы и т.п.). Это значительно упрощает поиск неисправности на объекте, или по рекламации клиента.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Подскажите, как вы делаете подготовку к релизу? Есть ли unit test'ы? Код ревью? Функциональное тестирование? Тесты на стабильность? 

Изменено пользователем SimpleSoft

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...