Всем привет.
На FreeRTOS вертятся 3 задачи, больше ничего из инструментария ОС не пользую.
Так вот когда configTICK_RATE_HZ установлен 1000Hz, все работает без проблем. Меняю это значение на 10000Hz, после ресета все задачи какое то время работают, а потом работает только одна - 2-я задача (скорее работает просто функция). Шедуллер перестает работать вовсе - vApplicationTickHook перестает вызываться и задачи не переключаются.
МК STM32L152rc работает на 16MHz.
В чем может быть дело?
Как отследить где планировщик заткнулся и почему?

Может стоит попробовать поочередно в каждой задаче не вызывать ничего иного кроме , например sleep(1000), или как там оно во ФриРтос. (я использую ChibiOs) Таким образом определиться, какая именно задача вешает шедулер, и уж потом исследовать ее под микроскопом.

1. Воспользоваться JTAG или SWD.
2. Если код задач небольшой, то привести его тут.
3. А есть уверенность, что при тике 1 кГц всё работает правильно?

Работа самого планировщика не укладывается в период, который Вы задали. Одна задача осталась - в соотв-ии с приоритетом.
Поставьте в каждую задачу "ногодрыг" (а лучше - и в планировщик). Где собака порылась будет видно в реалтайм.

Да, и это. + поставьте равные приоритеты для задач.

Кстати, ДА! Вспомнил, что когда-то читал о тиках планировщика. В голове отложилось, не делать менее 1 мс. Кстати, использовал эту цифру всегда, начиная с AVR и заканчивая Cortex-M4. Операционки: scmRTOS, FreeRTOS.

Да при тике 1кгц все работает.
2-я задача читает блоками аудио файл с флешь и DMA его пересылает в DAC. Она то и оставалась работать. Я ее отключил.

1-я задача обрабатывает сенсорные кнопки библиотекой touch-sensing library от ST. Собственно вызывает функцию, которая возвращает состояние кнопок. И если кнопка нажата, устанавливает глобальный флаг.
3-я задача проверяет этот флаг, когда он установился, запускает два таймера, один читает IR код с фотоприемника, а второй его передает.

Сразу оговорюсь, с ARM только начал разбираться, так что некоторые мои рассуждения могут быть глупые, не судите строго .

Глючит именно пара задач 1 и 3.
Причем если я блокирую одну из них, глюк пропадает.
У меня пока один вариант:
- библиотека touch-sensing library как то конфликтует с FreeRTOS.

Сейчас просматриваю не использует ли она какие то аппаратные ресурсы что и ОС, например SysTickTimer.




В планировщик больше вообще не попадаем после глюка. Надо проверить что там с прерываниями SysTickTimer, которые где то в FreeRTOS

По ходу прерывания SysTick отключаются. Точнее я вижу что в структуре описания этого регистра меняется значение CTRL - при старте CTRL = 0х00000007 / 0х00010007, а после глюка 0х00010005, и больше в прерывание не попадаем. Сейчас поставил частоту 20000Нz и глюк начал проявляться практически сразу.

Кроме всего, проверьте значения стеков задач (не помню, в FreeRTOS он общий или индивидуальные).
В настройках ОС задайте максимум, насколько позволит RAM. Если используются библиотеки - трудно сказать, как они потребляют стековую память.
Вместо "библиотечной" клавиатуры поставьте обычные кнопки или софт-эмулятор или эмулятор через USART.
Клавиатурная задача - самый низкий приоритет. Когда заработает "как надо" - прикрутите.
Аналогично Если есть осцилограф - ловится "на-раз" ногодрыгом.
Можно также под отладчиком поставить контрольную точку по состоянию (изменение) на требуемый регистр.

В Кеил брекпоинт можно поставить только на весь регистр, вот если бы на изменение бита.
Глючит из за библиотеки, там в прерывании таймера, у меня TIM3, вызывается некая функция обработчика этих кнопок. Вот тут то и происходит баг.

Апп. прерывания надо переносить под FreeRTOS иначе . . .
Соотв-но "напрямую" использовать библиотеки с апп. прерываниями без адаптации - могут быть "варианты". IMHO (чтобы не подрались с прерыванием планировщика).

Не понял что значит переносить под FreeRTOS?
Какие могут быть коллизии, если FreeRTOS использует прерывания с самыми высокими приоритетами? Я же обработчик делаю на низкоприоритетных TIM3 приоритет 36, а SysTick приоритет 6;

В общем из за малого опыта, тажело судить что происходит, но причина выявлена - 100% перестает работать SysTick, а соответственно и scheduler который крутится на этом таймере.
Вот только что происходит с SysTick, понять не могу.

Кто может, опишите регистры SysTick или ткните где посмотреть.

PS:
Судя по функции SysTick_Config там всего 3 бита, интуитивно по названиям дефайнов SysTick_CTRL_CLKSOURCE_Msk, SysTick_CTRL_TICKINT_Msk, SysTick_CTRL_ENABLE_Msk. один включает тактирование, второй инициализирует и третий запускает. Вот этот SysTick_CTRL_TICKINT_Msk и сбрасывается. Где не могу поймать. если бы в Кеил можно было установить брекпоинт на запись в бит. Кто знает можно такое?

Файлик STMTouch_Driver_um.chm
Раздел STM32L1xx resources used



Из прерывания SysTick'а они вызывают TSL_tim_ProcessIT().
Должны, во всяком случае.
И, видимо, как-то некорректно работают с

во всяком случае, каких-то других способов отключения таймера я сходу не нашёл.

А вообще - покажите регистры SYSTICK'а после ошибки.
Описание можно посмотреть на arm.com.

Я функцию TSL_tim_ProcessIT перенес в TIM3. Возможно у них где то в инициализации есть управление SysTick, буду искать. Спасибо за наводку.

У FreeRTOS свой стек для каждой задачи.

Кстати, автору топика рекомендую включить ловушки на нехватку памяти (настройки оси), использовать configASSERT'ы (настройки ОСИ), а также повесить обработчик на hardfault. Все эти вещи НЕ РАЗ выручали меня при отладке проекта.



На всякий случай)))

Очевидно, это процессор-зависимое требование. Возможно для ARM и не требуется.
В Demo FreeRTOS serial.c для STM32L152 в обработчике используется макрос portEND_SWITCHING_ISR( . . . ).

Ну вот и включение/выключение прерываний в коде этой тачлиб надо перенести на таймер 3. NVIC_Enable() / NVIC_Disable().

... а, по-хорошему, выкинуть их г-нокод задержек и переписать без критических секций.

Даже в толстых проектах никогда не ставлю больше 1000, а обычно вполне хватает 100.
Все остальные более точные времена и задержки следует реализовывать через аппаратные таймера и будить задачи из прерываний флагами или семафорами.


Вангую - в таком режиме либо не хватает основного стека (см. MSP) либо "кончается" стек одной из задач (PSP).
Ставьте контроль стека в настойках freeRTOS, и соотв. ловушки.

Зы. Как stress-test подобный "садизм" с таких космическим соотношением: 16МГц / 10кГц - имхо, вполне годное решение, возьму на вооружение

Тоже никогда не делал меньше 1 мс. Зачем вам это понадобилось?

Задачи обработки информации и событий "разложены" недостаточно неэффективно.
может так ?
приоритет High - "RealtimeTask" + IRQ
приоритет Middle - "DriverTask"
приоритет Low - "ApplicationTask"
приоритет LowLow - "GUI_keyb_console_Task"

Длительность системного такта не имеет отношения к этому.
Если загрузка СPU достигает 100% (ни разу не запускается IDLE задача), то нужно либо поднимать таковую частоту ядра, либо уменьшать частоту системного таймера ОС.
А правильнее - искать виновника: какая из задач "гадит в общую кастрюлю".
Слепая игра с приоритетами - это как молитвы о спасении умирающему: в самом лучшем случае лишь немного отсрочат неизбежную "кончину"

С памятью все ок!
Ловушки хоть и примитивные - бесконечный цикл (для отладки сгодится) везде стоят: vApplicationStackOverflowHook, HardFault_Handler и т.д.


Я не проект готовый делаю, а только разбираюсь. С STM и FreeRTOS, ранее не работал. Нужно было сделать захват сигнала с частотой 10мкс. Думал попробовать на таймере ОС, вот и поднял частоту. То оказалась глупая затея, а вот баг вылез. Вот и хочу разобраться, чтоб потом таких грабель не было.

Нашел костыль.
В функции обработка кнопок есть дефайн отключения а потом включения прерываний.
Там осталось от оригинала управление SysTick:

, а я кручу тайминг на TIM3.
Только пока не могу понять как это приводит к полному отключению прерываний. Проверил все места где disableInterrupts применяется, всегда есть обратный на включение enableInterrupts, а пока SysTick отключен, планировщик ведь не может передать управление. Дело в том что функция в которой SysTick включается/отключается вызывается из задачи 1, а когда происходит баг, программа весит в задаче 2.

Это еще мягко сказано! Это настоящие грабли!
Впервые вижу такую дичь

Берите готовые решения от FreeRTOS, там есть нужные макросы.

Нужные макросы чего?
Просто эта библиотека TouchSensorLib была заточена под SysTick. Ее нужно перебирать. Только хрена было ее делать под хардтимер не понятно.
Там и так хренова куча настроек, ну добавили бы еще одну по выбору и настройке таймера. Тем более что там нужно только мсек и сек считать и все!

Заделал такое:

Все вроде работает.
Осталось проверить чтоб теперь TIM3 не вис. Если будет виснуть, тогда косяк где то в TouchSensorLib.

Как чего? Критических секций: пара disableInterrupts/enableInterrupts именно для этого и тут и создана.


Ясень пень, что влоб такие вещи не решаются, иначе получается именно такой результат, как в "шапке" темы.
Или искать эту библиотеку, уже переделанную под FreeRTOS, где-нить на гитхабе или типа того

Сообщения #11 и #15 в этом топике не читали? ладно, следующий раз постараюсь более внятно излагать свои мысли.



Например, если задача 2 более высокоприоритетная, и устроена как-то следующим образом:
while (1) {
wait_mutex(); // queue/...
do_job();
sleep(N);
}
а это внешний мьютекс или элемент из очереди привязан не к SysTick'у, а к какому-то внешнему воздействию, она может проснуться в т.ч. и в тот момент, когда задача 1 находится внутри критической секции. И всё - из sleep'а мы никогда не выйдем...

А какой смысл в замене SysTick на TIM3? В Ваш МК SysTick впаять забыли?


Почему?

Вот не копал глубоко - при использовании мастера CubeMX + FreeRtos
ПО советует использовать другой кроме SysTic таймер.
"Явление открыл - причин не измышляю"(Ломоносов).

хммм.... Если это так, то это причина не заменить таймер, а выбросить нафиг куб вместе с фриртос-ом (или его кривым портом).

Фриртос вполне годная вещь, и порты в целом годные, но в погоне за универсальностью (поддержка огромного числа платформ) вся ось стала монстроподобной и потому не самой шустрой и удобной.
Но запускается с полпинка и вполне годно работает, но при условии: делать все правильно и не заниматься самодеятельностью (как это делает ТС).

FreeRTOS работает хорошо и правильно, если с ней правильно работать...
А вот прикручивать таймеры общего назначения вместо специально интегрированного в ядро Cortex-Mx SysTick - ИМХО попахивает аттавизмом из 8-битных микроконтроллеров, где и другого выбора-то не было.

Этот пост я проглядел. то есть не совсем проглядел, а проглядывал его с телефона дома, и не особо придал значение коду с дефайнами. После продолжение ветки перешло на второй лист, и туда забыл посмотреть. Но зато комент, где было сказано что тачлиб юзает SysTick натолкнула на мысль, что нужно из нее удалить все упоминания SysTick чтоб она вообще забыла о его существовании.
По этому автору esaulenka отдельное спасибо.

Это все хорошо.
Только мне не понятен один момент, откинув всю лирику о приоритетах задач, концепции FreeRTOS и т.д.
Планировщик, очень сокращенно - это функция которая управляет регистром PC, то есть выбирает куда перекинуть ход выполнения программы.
Он вызывается по прерыванию таймера на котором он работает - SysTick, или через API функции FreeRTOSа.
У меня 3 задачи, не в одной нет никаких API функций, даже делай.
1-я вызывает функцию, которая отключает SysTick и по какой то причине он не включается. Каким образом моя программа оказывается во второй задачи и там висит, потому как SysTick отключен и планировщик больше не вызывается, а API функций в задачах нет, чтоб вызвать планировщик.

P.S. Остается только один вариант - когда 1-я задача включает SysTick, срабатывает прерывание, мы попадаем в планировщик, он передает управление 2-й задаче, и тут по какой то причине SysTick отключается (уже в планировщике).

При использовании STMовского HAL (CubeMX) + FreeRTOS нужно назначать системный таймер HALа (который формирует сетку 1 мс) на любой другой свободный таймер кроме SysTick. Потому что SysTick монопольно занимает FreeRTOS.
И приоритеты на них назначаются соответственно.
Это подробно описано в доках на HAL, целая глава есть.

А по минимальному тику FreeRTOS тоже встречал рекомендации не делать частоту больше 1000 гц
Из доки на FreeRTOS v9.0 :

То есть, если в ваших библиотеках применяется макрос pdMS_TO_TICKS(), то он будет неправильно считать время.

Что то кажется мне, что дело не в тачлиб, во второй задаче у меня используется FatFS, я ее прикрутил и просто читаю файл через SPI. Но сейчас вспоминаю, когда я с ней разбирался (поверхностно) особо на детали внимание не обращал, меня интересовало только чтение файла. Но там ведь где то должны быть часы, чтоб указывать время создания/редактирования файла (по идеи). То есть эта библиотека как то должна работать со временем, а где это делается и настраивается я даже не разбирался. Возможно это вторая задача SysTick останавливает.

P.S.
Хотя вроде нужно самому эти атрибуты заполнять, FatFS за датой не следит, по крайне мере настраивать ее я не находил как. Там есть структура FILINFO, вот пользователь ее сам и заполняет.

Судя по всему у вас нет не хватает знаний по RTOS, читайте матчасть, она есть на сайте freeRTOS.
В частности примеры применения.
Тогда не придется гадать на кофейной гуще ))

Мне тоже она показалась слишком монстроидальной. Поэтому пользую uCOS-II - она полегче.


Обычно в РТОС он вызывается не только из ISR таймера и вызовов API OS, но и в других ISR (в которых это разрешено).


Ну так можно вызвать нужную функцию этого куба из ISR FreeRTOS. Выставить для FreeRTOS 1КГЦ и вызывать.
Нафига козе баян Зачем кста кубу это прерывание? Там своя ОС внутри уже что-ль?


Кста: не планировщик (шедулер) перекидывает ход выполнения программы, а переключатель контекста. Если уж на то пошло.
Шедулер только выбирает и назначает какая задача будет выполняться следующей, и возбуждает PendSV, в котором собственно контекст и переключается. Без PendSV ничего никуда не перекинется.

Тоже смотрел в сторону uCOS, но уже uCOS-III.
Но "вдруг" попалась под руки RTX Keil (теперь она кстати принадлежит ARM), сделана по-уму: все сервисы на SVC, т.е. именно так, как это рекомендуется самой АRM при проектировании ядра.
Работает несколько быстрее FreeRTOS, размера занимает немного меньше. Сравнивал на одном и том же проекте.

На самом деле, сделать частоту тиков выше не проблема. Ну да, придётся переписать пару простых макросов и на этом всё.
Использую в сложном проекте где порядка 60 задач, частоту тиков почти 13кГц, при тактовой 96МГц, отлично работает.

Зачем это надо. Объясняю. Если используете энергосберегающие режимы и режим ticklessIdle, т.е. пропуск тиков, то в сон контроллер уходит не ранее чем через один тик, соответственно чем тик меньше, тем быстрее после выполнения задачи контроллер уснёт.


Я правильно понял, что в задачах нет вызовов vTaskDelay()?
В таком случае они всегда будут подвешивать планировщик.
vTaskDelay() обязателен в любой задаче FreeRTOS.
Хотя вру, не обязателен, вместо него может быть ожидание очереди или семафора, но что-то подобное обязано быть внутри бесконечного цикла каждой задачи.

Что значит "несколько быстрее"? Изменилась загрузка CPU? И на сколько (в %)?

Да, загрузка меньше, буквально проценты, но конкретное значение сильно зависит от проекта.
Т.е. если использутся очень много сервисов, то разница получается более заметная.
Полагаю, что все дело в более оптимальной работе шедулера и самих сервисов.
Точные замеры (профилирование) я не делал, ибо такой задачи себе не ставил.
Просто, было принято решение выбора: соскакивать с FreeRTOS или остаться. Выбор пал на первое ))


Ну и вторым доводом сыграло то, что мои проекты не привязаны к какой-то конкретной RTOS (раньше я об этом писал, использую "обертку"), но почти все проекты на ARM-Cortex.
Поэтому тащить чудовищную универсальность в плане портов FreeRTOS для меня просто нет смысла.

Но есть и минус (для меня): пока что нет у Segger порта для их SystemView под эту ось, но дойдут руки сам сделаю или на край дождусь пока на это созреет Segger.
Порты SystemView на FreeRTOS и uCOS есть в комплекте, вполне рабочие. Правда порт SystemView под FreeRTOS пришлось немного допиливать - сыроват он был на тот момент ((

А про эту штуку знаете https://electronix.ru/forum/index.php?showtopic=127646 ? Вроде и под ucos ее уже сделали

Знаем такую, пробовали ))
Но лично мне она вообще не понравилась - вертикальная прокрутка (WTF???), информативность уступает systemview и нет нормальной FREE версии ((

У меня было такое же мнение о вертикальной прокрутке.
Но сейчас у меня противоложное мнение.
А J-link у вас настоящий? Тогда какая разница?
Как в горизонтальной прокрутке вывести столько инфы:
Нажмите для просмотра прикрепленного файла

Поясните, не пойму связи. J-link-ов в конторе много и нормальные и китай.
Придет время купят и SystemView, но пока 1млн событий (ограничение free версии) хватает в любом нынешнем проекте.

В SystemView все события (текст) точно также выводятся c вертикальной прокруткой.
Если щелкнуть на любое событие в окне терминала или событий, то на графике автоматом будет указано место.
Удобно и главное - привычно: ось времени - X, слева направо. Никакой самодеятельности ))

Нажмите для просмотра прикрепленного файла

Нет. Если задачи одного приоритета, они будут переключаться по кругу с периодом SYSTICK.
Не самая лучшая идея, но работает.

Заодно мы решили загадку топикстартера. Переключение задач у него не привязано к выполнению задачи никак, и в какой-то "счастливый" момент оно срабатывает посреди критической секции. Один раз.
В общем, это никуда не годится. Если есть RTOS, надо ей пользоваться. Нужна задержка - delay() операционки. Нужно подождать, пока сработает прерывание - выкинуть вечный цикл с флажком, сделать очередь или семафор.



Классика. Пастернака не читал, но осуждаю. Извините.

Я конечно извиняю за ваше незнание Пастернака. Но какое он имеет отношение к моему вопросу?

Потихоньку разбираюсь далее с FreeRTOS.
Возникла новая проблема, я ее решил но возможно не совсем правильно и не понимаю из за чего так получилось.
Сейчас системный тик 1мсек.
Может кто подскажет?

Есть таймер настроенный на 10мкс, на каждом прерывании он декрементирует глоб. переменную, значение которой задает Task2 (имеет самый высокий приоритет).
Когда переменная = 0, устанавливает семафор, чтоб разбудить задачу, которая установит новое значение переменной.

В общем пока я не начал отключать прерывания таймера (в коде выделил), все висло в обработчике таймера и ни одна задача управление не получает.

Чтобы на столь высоких частотах периодических прерываний работало и не висло, нужно вначале научиться обходиться без куба.
И потрудитесь хотя-бы посчитать каков период прерываний в тактах ядра.

Где тут куб увидели?
Ядра чего ОС? Если да то я писал 1мсек.

P.S. На всякий случай, частота тактирования МК - 16МГц.

Естественно тактах CPU.
Если не куб, то кубоподбный код: TIM_GetFlagStatus(), TIM_ClearFlag()
у Вас всего 160 тактов между прерываниями, за которые CPU должен успеть кучу всего (откройте листинг и вручную посчитайте такты или то же самое сделайте отладчиком).
Даже если писать нормально (с прямой работой с регистрами IO, без ненужных функций) при такой высокой частоте у Вас CPU только и будет заниматься входами/выходами в ISR - загрузка будет близка к 100%.
А при обнулении счётчика так вообще там у Вас таймер наверняка переполняется и что-то при этом происходит.
Вам надо кардинально пересматривать архитектуру проекта и или повышать частоту CPU или обходиться без таких ВЧ прерываний. И научиться работать с регистрами напрямую, без ненужных обёрток.

1600