[Valentinus 1]

коллеги, прошу помощи.

используем платку SOM-TLIMX8 от китайцев (ф. Тронлонг) на процессоре I.MX8

столкнулись с проблемой - сопроцессор М4 периодически начинает работать медленнее.

 

изначально нам нужно было чтоб периодически (по таймеру) М4 выдавал некоторую диаграмму по GPIO (вся диаграмма выдается за одно прерывание, т.е. ее длина зависит только от быстродействия М4)

И мы увидели что диаграмма меняет длительность: то нормальная, то в несколько раз шире, то есть как будто М4 меняет частоту на которой работает.

мы подумали , что может где-то ошиблись, что-то неправильно задали в DTS, и тогда вместо работы с GPIO вставили просто цикл загружающий М4 работой (в цикле складывали числа от 0 до 1000) и замеряли его время (по тикам таймера).

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

и тогда взяли для пример с сайта NXP, который показывает работы с GPT таймером.

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

и в начало обработчика мы поставили тот же цикл и замером времени его работы, типа такого:

 

int summ = 0 , t1 , t2 ;

/ **********  Code ***** /

void EXAMPLE_GPT_IRQHandler ( void ) {

/ * Clear interrupt flag . * /

GPT_ClearStatusFlags ( EXAMPLE_GPT , KGPT_Output Compare1Flag ) ;

t1 = GPT_GetCurrentTimerCount ( EXAMPLE_GPT ) ;

for ( int i = 0 ; i < 1; i ++ ) { summ + = i ; } // dummy loop

t2 = GPT GetCurrentTimerCount ( EXAMPLE_GPT ) ;

PRINTF ( " time = % d \ n \ r " , t2 - t1 ) ;

/ **************** /

 

и после запуска получили ту же картину, значение time в консоли скачет.

То есть, проблема не из-за наших кривых рук.

 

вот тут видео: https://drive.google.com/file/d/1PUPp5DT9KaArDjHAgyDeLWuTQpQiRJXo/view?usp=sharing (для наглядности тут увеличено количество итераций и частота таймера)

 

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

потом на каком-то этапе он начинает тормозиться,  примерно когда загрузка доходит до монтирования носителей, а после окончания загрузки тормозит почти постоянно. если запустить копирование с sd на emmc то во время копирования скорость М4 снова нормальная. если остановить ОС (halt) то все снова норм.

 

Подскажите , плиз, в чем может быть проблема, куда копать? уже всю голову сломали 😞

 

 

 

 

Изменено 25 октября, 2022 пользователем Valentinus

[jcxz 184]

45 минут назад, Valentinus сказал:

изначально нам нужно было чтоб периодически (по таймеру) М4 выдавал некоторую диаграмму по GPIO (вся диаграмма выдается за одно прерывание, т.е. ее длина зависит только от быстродействия М4)

У вас временная диаграмма сигнала на GPIO определяется скоростью выполнения кода M4-ядром? И при этом есть требования к точной (до тактов) выдержки её таймингов??  

Это изначально тупиковый путь. Тем более на многоядерном МК. На котором наверняка есть и кеш и DMA и возможно другие транзакции по шинам, используемым M4. M4 - это не AVR.

 

Для формирования произвольных временых диаграмм сигналов в некоторых NXP-процессорах имеется SGPIO. Вот SGPIO - правильное решение для генерации произвольного сигнала с точностью до такта.

[Valentinus 1]

9 minutes ago, jcxz said:

У вас временная диаграмма сигнала на GPIO определяется скоростью выполнения кода M4-ядром? И при этом есть требования к точной (до тактов) выдержки её таймингов??  

Это изначально тупиковый путь. Тем более на многоядерном МК. На котором наверняка есть и кеш и DMA и возможно другие транзакции по шинам, используемым M4. M4 - это не AVR.

 

Для формирования произвольных временых диаграмм сигналов в некоторых NXP-процессорах имеется SGPIO. Вот SGPIO - правильное решение для генерации произвольного сигнала с точностью до такта.

это в данном случае не важно, переферия нестандартная, она не может по DMA и ее устраивает скорость М4.

но нас не устраивает то что М4 меняет свою частоту работы, и не можем понять - из-за чего?

[jcxz 184]

12 минут назад, Valentinus сказал:

это в данном случае не важно, переферия нестандартная, она не может по DMA и ее устраивает скорость М4.

При чём тут "она не может по DMA"?    Я вроде и не предлагал. Я предлагал SGPIO.

12 минут назад, Valentinus сказал:

но нас не устраивает то что М4 меняет свою частоту работы, и не можем понять - из-за чего?

С чего решили что "М4 меняет свою частоту работы"?

[Valentinus 1]

46 minutes ago, jcxz said:

Я предлагал SGPIO.

скажу проще: у нас был проект на i.MX6, там все работает на GPIO , отлажено, он рабочий, но эту плату больше не продают,  и нам надо его перенести на другую плату с i.MX8 с минимальными доработками. и уже почти все сделали, но вот столкнулись с описанной проблемой.

48 minutes ago, jcxz said:

С чего решили что "М4 меняет свою частоту работы"?

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

у меня были версии, что прерывание таймера прерывается каким-то еще более приоритетным, но временная диаграмма у нас растягивается ровно. то есть просто код в М4 вдруг начинает выполняться медленнее.

[jcxz 184]

14 минут назад, Valentinus сказал:

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

Причин может быть миллион:

1) Код M4 выполняется из той же памяти, что и код выполняемый другим ядром. Из-за этого шина доступа к этой памяти разделяется обращениями разных bus-masters, соответствено тормозя оба ядра или одно из них (менее приоритетное). Или/и не код, а данные/периферия, к которым обращаются эти ядра - находятся на одной шине.

2) Работает DMA, использующий память/периферию, находящуюся на тех же шинах, что и используемая M4-ядром. Опять идёт разделение общего ресурса - шины.

3) Возможно имеется кеш, разделяемый несколькими ядрами МК. Тогда при активном выполнении кода на другом ядре, его обращения за командами/данными может вытеснять команды/код M4-ядра, заставляя его заново перечитывать их из памяти.

...

Какого хоть порядка замедления? Такты? Десятки тактов? Тысячи? ...

14 минут назад, Valentinus сказал:

у меня были версии, что прерывание таймера прерывается каким-то еще более приоритетным, но временная диаграмма у нас растягивается ровно. то есть просто код в М4 вдруг начинает выполняться медленнее.

А вы учитываете, что время входа в ISR на Cortex-M может быть очень разным? Как фишка ляжет. При наличии других прерываний (на том же уровне приоритета) может происходить tail-chaining. Почитайте что это такое.

[Valentinus 1]

1 hour ago, jcxz said:

Причин может быть миллион:

1) Код M4 выполняется из той же памяти, что и код выполняемый другим ядром. Из-за этого шина доступа к этой памяти разделяется обращениями разных bus-masters, соответствено тормозя оба ядра или одно из них (менее приоритетное). Или/и не код, а данные/периферия, к которым обращаются эти ядра - находятся на одной шине.

2) Работает DMA, использующий память/периферию, находящуюся на тех же шинах, что и используемая M4-ядром. Опять идёт разделение общего ресурса - шины.

3) Возможно имеется кеш, разделяемый несколькими ядрами МК. Тогда при активном выполнении кода на другом ядре, его обращения за командами/данными может вытеснять команды/код M4-ядра, заставляя его заново перечитывать их из памяти.

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

и как я писал в изначальном сообщении, для исключения вероятности таких вот конфликтов мы взяли простейший пример от производителя проца, и вставили туда только измерение времени выполнения прерывания. т.е. конкуренции за доступ к внешним устройствам нет.

более того, если  запустить например копирование большого файла , то скорость М4 становится нормальной (на время копирования). то есть дело не в конкуренции за шину или память.

у меня есть подозрение что после загрузки , до командной строки, ОС как бы понимает что наступил режим простоя и снижает тактовую частоту основных ядер, и М4 заодно. но как проверить эту теорию и как этому помешать я не знаю.

1 hour ago, jcxz said:

Какого хоть порядка замедления? Такты? Десятки тактов? Тысячи? ...

в несколько раз. т.е. при нормальной "скорости" диаграмма занимает примерно 12мкс, при замедленной - порядка 70мкс

1 hour ago, jcxz said:

А вы учитываете, что время входа в ISR на Cortex-M может быть очень разным?

Время входа в ISR очень стабильное,  к нему нет абсолютно никаких вопросов ))) вопрос к времени выполнения самого ISR

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

[jcxz 184]

24 минуты назад, Valentinus сказал:

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

Возможно что не снижает, а просто вводит в какой-то sleep-режим, выход из которого требует некоторого времени. Если используется генератор (особенно кварцевый) и в sleep-режиме он останавливается, то при выходе из этого режима необходимо время на разгон генератора. Сколько времени - зависит от того какой генератор используется для тактирования M4. RC-генератор например требует меньше времени на разгон.

Я у себя в ОС, в idle-задаче, всегда кладу спать Cortex-M-ядро в сон пока оно не нужно. Это вроде как правило хорошего тона. Даже если питание не батарейное. Правда в сон кладу обычно в мелкий - без останова генератора. Тогда ядро просыпается почти мгновенно.

24 минуты назад, Valentinus сказал:

но как проверить эту теорию и как этому помешать я не знаю.

Кто же мешает вам найти регистры МК, отвечающие за сон и посмотреть их содержимое? Или дождаться простоя CPU и остановить отладчиком его? Найдёте место в коде.

Ещё можно тупо, вручную, найти инструкции WFE/WFI в коде и поставить бряки на них.

24 минуты назад, Valentinus сказал:

в несколько раз. т.е. при нормальной "скорости" диаграмма занимает примерно 12мкс, при замедленной - порядка 70мкс

Судя по времени - вполне похоже на время разгона генератора. А вот для перепрограммирования делителя частоты (изменения тактовой ядра) - слишком много времени. Если конечно у вас M4 не на 1 МГц тактовой работает.  

[Valentinus 1]

19 minutes ago, jcxz said:

Судя по времени - вполне похоже на время разгона генератора.

еще раз повторюсь - диаграмма пропорционально растягивается , из 12 мкс до 70мкс.

если бы задержка была из-за "разгона", то была бы просто задержка в начале.

[jcxz 184]

11 минут назад, Valentinus сказал:

еще раз повторюсь - диаграмма пропорционально растягивается , из 12 мкс до 70мкс.

Ну так остановите CPU внутри вашего ISR и посмотрите содержимое регистров конфигурации системы тактирования. В чём проблема?

[Valentinus 1]

оказалось проблема в CPU Frequency Scaling и Dynamic Bus Frequencies. Эти фичи меняют частоту М4, более подробно почитать  в I.MX Reference Manual главы 2.3.3 и 2.3.4.

запретить  Dynamic Bus Frequencies можно прям из командной строки:

echo 0 > /sys/devices/platform/busfreq/enable

Проблема решена.
Оставил комментарий для тех кто с эти столкнется.