[std 6]

Предпосылки: пришлось заново создать .ioc файл и перегенерить код проекта заново, т.к. CubeMX ver 6.4.0 стал виснуть при генерации кода после того как я руками понизил на единицу в .ioc файле FirmwarePackage, MxCube.Version, MxDb.Version.   В проекте ничего нет,  кроме ETH и LwIp.

Сравнивая код "что было и что стало" заметил, что в stm32f4xx_hal_conf.h:151 изменился приоритет TICK_INT_PRIORITY, было 0, стало почему-то 15. 

Что такое приоритет прерываний известно.  Но зачем бы это понадобилось System Tick сделать наименне приоритетным? В чем смысл, чем они руководствовались?

Скрытый текст

Package:  FW_F4 1.26.2. 
Изменили код либо STM32CubeMX ver 6.4.0,  либо STM32CubeIDE 1.9.0 (с его внутренним Cube версии 6.5.0) 

 

[Arlleex 131]

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

P.S. Ну вот. Стоило только погуглить.

[std 6]

1 час назад, Arlleex сказал:

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

P.S. Ну вот. Стоило только погуглить.

 Пока проблем нет.  Я исправил у себя приоритет снова на 0.  Но хотелось бы не наступить на проблемы в будущем, когда без какого-либо предупреждения обнаруживается что приоритет системного таймера стал вдруг наинизший в системе.  Коллекция HAL драйверов огромна и мутабельна от системы к системе, и как она использует SysTick бог его знает. К этому есть и другие Middleware и проч.

Было: TICK_INT_PRIORITY=0 — короткий SysTick_Handler всегда прерывал любые другие прерывания.
Стало: TICK_INT_PRIORITY=15  — любые другие прерывания всегда прерывают короткий SysTick_Handler (и он не может перебивать другие прерывания).

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

[Arlleex 131]

40 минут назад, std сказал:

Это называется не причесали быдлокод, а сломали.  Тихо и никому не говоря это происходить не должно.

Такова плата за использование чужого бесплатного быдлокода, увы.

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

P.S. Во FreeRTOS, например, приоритет SysTick тоже крайне низок. Ниже только непосредственно PendSV, который переключает контекст.

[jcxz 184]

50 минут назад, Arlleex сказал:

P.S. Во FreeRTOS, например, приоритет SysTick тоже крайне низок. Ниже только непосредственно PendSV, который переключает контекст.

Так и должно быть. По уму. В моих проектах на Cortex-M (с моей собственной ОС и ранее - с uCOS) тоже везде так: PendSV - самый низкий, Systick - следующий выше, ещё выше - прикладные ISR от аппаратуры.

PS: В Systick обычно происходит обслуживание списка задач ОС (обслуживание всех временнЫх событий в них (задержки, ожидания объектов синхронизации с таймаутами и пр.)). Глупо это делать с приоритетом выше прикладных аппаратных обработчиков. ...ну только если в каких-то особенных, редких случаях.

[std 6]

"Глупо" это несколько размытое понятие.  В общем, преследуется цель - исключить дополнительное  время в прерываниях. Оно может возникнуть потому что некое прерывание будет прервано более приоритетным SysTick.  Все очень сильно зависит от того, какой конкретный объем кода исполняется в  SysTick. 

Хммм.. Интересно, может ли что-то объемное и медленное в приоритетных прерываниях (вытесняющих обработчики HAL) серьезно нарушить работу ST HAL/LL ?  
(Да, документация на временнЫе параметры системы это большая редкость...)

Изменено 20 марта, 2022 пользователем std

[jcxz 184]

4 часа назад, std сказал:

"Глупо" это несколько размытое понятие.

"Глупо" - потому что состояния задач используются только переключателем задач ОС (ниже приоритетов всех ISR). Потому: глупо обслуживать эти состояния выше, чем на минимальном приоритете ISR, чуть выше PendSV.

[AVI-crak 0]

14 hours ago, std said:

любые другие прерывания всегда прерывают короткий SysTick_Handler (и он не может перебивать другие прерывания)

Это нормальное состояние для SysTick_Handler, который почти всегда используется для вызова более сильного прерывания - для переключения контекста. Отсутствие вытеснения слабых прерываний - гарантия сохранения чистого стека, что очень важно для переключения задач.

Вопрос в другом, как оно работало раньше??? 

[Arlleex 131]

5 часов назад, AVI-crak сказал:

Это нормальное состояние для SysTick_Handler, который почти всегда используется для вызова более сильного прерывания - для переключения контекста.

Здрасьте приехали. Приоритет переключателя контекста как раз-таки ниже ISR SysTick-а.

[std 6]

Я, кстати, как в воду глядел. Смешно!  У меня, похоже,  образовалась проблема с прерываниями и именно с приоритетом, но для этого я создам другую тему.
SysTick к этому вряд ли имеет отношение.

Какие тут интересные люди собрались. Все  со своей RTOS    Было бы интересно поучиться у профов, хотя бы парой вопросов. 
А) Какие IDE/либы предпочитаете в RTOS и системном уровне? Меня тут затащили на Atollic (Eclipse), а потом на STM32CubeIDE. Что-то говно какое-то, плююсь.  До этого использовал связку IAR + CLion.  Слабо щупаю KEIL, тоже такая "система в себе".  Что вы юзаете, на чем пишете RTOS и прочую? Интересует прежде всего, развитая отладка.
 

Б) Мне надо отладить прерывания. Ситуация типчиная, скорее всего мой цикл опроса BiSS с SPI DMA дубасит так, что вытесняет прерывания двух UART'ов (я это еще пока не проверил, гипотеза).
Чем можно исследовать время наступления прерываний, очередность и их продолжительность в системе? Segger SystemView? 

Пока отлаживался, поставил data watchpoint на RingBuffer, но указал не так как в обычном ARM компараторе, [read + adrress], а еще размер ячейки в байтах и с чем ее сравнивать. В процессе исполнения программы с этим брекпоинтом CRC-ошибки приема стали валить валом. Пока что гипотеза что для брекпоинта задействовано прерывание, которое еще больше вытесняет и без того вытесненные прерывания двух UART'ов.

Так вот, чем можно сесть вообще на ВСЕ прерывания в системе чтобы понять, какое из них дубасит столь часто?
Нет, конечно можно начать спектрумовские методы отладки, запустить таймер. В каждом прерывании (это на них еще надо сесть) крутить счетчики. Но может быть есть что-то посовременнее?

Изменено 24 марта, 2022 пользователем std

[jcxz 184]

47 минут назад, std сказал:

А) Какие IDE/либы предпочитаете в RTOS и системном уровне?

IAR.

47 минут назад, std сказал:

Чем можно исследовать время наступления прерываний, очередность и их продолжительность в системе? Segger SystemView? 

Например - таймером DWT.CYCCNT. Тикает на частоте ядра.

[std 6]

1 час назад, jcxz сказал:

IAR.

Например - таймером DWT.CYCCNT. Тикает на частоте ядра.

Да, есть такой. Только таймер пол-дела. Его тики нужно еще собрать, переслать и как-то отобразить на хосте.

[AVI-crak 0]

22 hours ago, std said:

Так вот, чем можно сесть вообще на ВСЕ прерывания в системе чтобы понять, какое из них дубасит столь часто?

Оценивать количество вызовов прерываний отладчиком - физически невозможно. Когда просматриваешь код отладчиком - выполнение кода встаёт колом, все независимые прерывания накапливаются в очереди, и после нового шага отладчика - ломануться выполняться всем скопом.

Можно поступить хитро, добавить простейший программный счётчик. Завести переменную, которую в вашем подозрительном прерывании увеличивать на 1. Используя рабочий таймер на 1 секунду (проще аппаратный) - считывать переменную во внешний показатор результата, а переменную после этого обнулять.  

Подобным способом пройтись по всему подозрительному, найти и устранить индийский код.