STM32F373R8 проблема с АЦП+ПДП и сторожем таймером, При работе с таймером в беск. цикле, замедляется сбор данных с АЦП Опции

[ZiB]

Добрый день!

Столкнулся с проблемкой на STM32F373R8 (возможно есть и на других мк, пока не было времени проверить).

Системная тактовая частота 12 МГц.

Работаю с АЦП1 (12 битное).
Предделитель АЦП = 2.
АЦП настроено на непрерывное преобразование с минимальным временем выборки.
Частота преобразований получается (12МГц/2)/(14 тактов одно преобразование) = ~430 кГц.

Данные с АЦП забирает ПДП (DMA) контроллер.

Все работает прекрасно.

Однако когда в коде встречается цилический доступ к регистрам сторожевого таймера, то частота преобразований падет до 190 кГц.

Код

    while (1)
    {
        IWDG->KR = 0xAAAA;
    }

Проверял с регистрами IWDG->RLR, IWDG->PR.

Активность таймера не влияет на ошибку (т.е. и со включенным и с выключенным таймером).

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

Может кто сталкивался с данной проблемкой и знает, где почитать более детально о работе ПДП и задрежках на шинах ?

[vlad_new]

M3 делит шину между ядром и ДМА с коэффициентом 1:3. Как они делятся в М4 незнаю. Читать надо.

[Flexz]

Тут еще другое интересно - в других процессорах серии (F1/2/4) в регистре статуса АЦП присутствует бит Overflow, который устанавливается в 1 в случае если DMA не успевает забрать данные из DR. При этом АЦП останавливается, что защищает от получения перепутанных данных (при преобразовании последовательности каналов).
В F37x такого бита нет, и что происходит, если DMA не успевает забрать данные - мануал умалчивает. Видимо, данные по-тихому теряются.

[ZiB]

Спасибо за ответы.
Я пока полностью не разобрался.
Аналогичный код на STM32F100 и STM32F407, работает без проблем.
Заказал аналогичный мк с большей памятью STM32F373RB, посмотрим, что там будет.
Сейчас хочу попробовать использовать другие модули, не АЦП и посмотреть как будет с ними работать ПДП.

[jcxz]

M3 делит шину между ядром и ДМА с коэффициентом 1:3. Как они делятся в М4 незнаю. Читать надо.

Хм.... Это где такое написано? Можно ссылку?

[_Артём_]

Хм.... Это где такое написано? Можно ссылку?

Нужно искать в reference manual раздел Memory and bus architecture
что-то типа такого:

BusMatrix
The BusMatrix manages the access arbitration between the core system bus and the DMA
master bus. The arbitration uses a Round Robin algorithm. In connectivity line devices, the
BusMatrix is composed of five masters (CPU DCode, System bus, Ethernet DMA, DMA1
and DMA2 bus) and three slaves (FLITF, SRAM and AHB2APB bridges). In other devices,
the BusMatrix is composed of four masters (CPU DCode, System bus, DMA1 bus and
DMA2 bus) and four slaves (FLITF, SRAM, FSMC and AHB2APB bridges).
AHB peripherals are connected on system bus through a BusMatrix to allow DMA access.

[ZiB]

Это, то все понятно (что ЦПУ и ПДП делят шину и есть ограничения по пропускной способности), но не понятно, почему при обращении к регистрам сторожевого таймера происходит "задержки" и по всей видимости только на STM32F3. Сейчас платы нет под рукой, в пн. продолжу тестирование.

Почитать о работе ПДП по нашему и с красивыми картинками можно тут (для М3) http://www.gaw.ru/html.cgi/txt/doc/micros/...x_arh/4_2_3.htm

[Golikov A.]

может обращение к сторожевому таймеру вынесено в высший приоритет? То есть не блокируется ничем, и когда вы в него в цикле долбитесь ДМА просто не находит места для своих посылок?

[vlad_new]

Чего тут предполагать, когда АЦП и сторожевик сидят на одной шине. У F3 это вроде бы AHB1 (ну не помню точно, да это и не важно).

[ZiB]

С чего это? Это где такое написано ?

[Flexz]

Раздел System architecture, почти вся периферия, кроме GPIO, сидит на одном AHB-APB мосту.
Пересылка с помощью DMA занимает минимум пять тактов, а цикл из первого поста, если не ошибаюсь, выполняется за три. Вот и выходит, что ядро и DMA почти постоянно заняты дележкой шины.

[jcxz]

Нужно искать в reference manual раздел Memory and bus architecture
что-то типа такого:

Просматривал все разделы связанные с AHB Bus Matrix. Нигде не нашёл численных значений приоритетов доступа к шине. LPC17xx.

Кста - LPC1778 нормально работает при интенсивных параллельных DMA-транзакциях с двумя SSP (один на 20МГц, другой - 30МГц), программно-эмулированном UART (ещё один канал 9600*16 Гц запросы GPIO->GPDMA) и при этом - параллельной работе процессора с периодическим обращением к другой различной периферии. Итого сейчас - до 5 параллельно работающих GPDMA-каналов + работа CPU в многозадачной ОС со множеством активной периферии.
Правда использую два SSP сидящие на разных APB-мостах. GPIO также - прямо на AHB.
Наивысший приоритет доступа к шине выставлен для DMA (в LPC1778 можно задать приоритет доступа к шине для GPDMA выше чем CPU).
Скоро наверное туда ещё добавлю непрерывный поток ADC->GPDMA хотя не на такой большой частоте как у топикстартера. Посмотрим...

Да - системная CLK у меня ==120МГц.
Итого в сумме поток через DMA идёт интенсивнее чем у топикстартера (даже относительно системной CLK). При этом вроде проблем не наблюдается.
А зачем топикстартеру такая низкая системная CLK - 12МГц? Может просто попробовать поднять?

[_Артём_]

Просматривал все разделы связанные с AHB Bus Matrix. Нигде не нашёл численных значений приоритетов доступа к шине. LPC17xx.

Как-то у них неподробно описано(UM10360.pdf):

2.5 AHB arbitration
The Multilayer AHB Matrix arbitrates between several masters. By default, the Cortex-M3
D-code bus has the highest priority, followed by the I-Code bus. All other masters share a
lower priority.

[ZiB]

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

На пересылку должно уходить не более 14 тактов (АЦП необходимо столько для преобразования данных), если судить по описанию доступ к шине занимает 5 тактов, остаеться ещё 9 тактов, чего тоже достаточно.
Да и раньше это все прекрасно работало на STM32F405 (я и сейчас отдельно проверял, выше уже писал).
Прешел на STM32F3, так как необходимо 16-ти битное АЦП. Все прекрасно запустилось, думал будет сильно шуметь из-за очень плотного монтажа, но получилось хорошо, уровень шума мал.

Попробую ещё на STM32F303 (Discovery), но там АЦП другое.

Работал, бы на ещё меньшей тактовой частоте для меньшего потребления, но необходимо оцифровывать один канал с частотой не ниже 400 кГц.

Хм, на STM32F303, все работает прекрасно... (При чем на 12 МГц, успевает пересылать в два раза больше данных, у него делитель на АЦП от 1.)

Эх, поехал на работу за платой, что-то мне эта проблемка покоя не дает. Хоть бы это мой косяк был, а не косяк в мк.

Забыл скрины подписать. Левый STM32F3, правый STM32F4.

Эскизы прикрепленных изображений

 

[jcxz]

Работать на бОльшей и много спать.