Добрый день!

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Просматривал все разделы связанные с 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МГц? Может просто попробовать поднять?

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

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

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

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

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

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

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

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

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

Сходил за платой...

Нашел место, но не понял причину.

Странная штука получается, в обоих мк (STM32F303 и STM32F373) независимый таймер подключен к шине АВР1, правда АЦП сидят на разных шинах.
В 303 снижение частоты АВР1 в 16 раз, ни дает ни какого эффекта, а вот в 373 это приводит к торможению обмена АЦП, хотя АЦП подключен к APB2.

В 100-ом похожая структура и там тоже аналогичная ситуация, процесс передачи данных замедляется.

В 407-ом замедления нет, но структура похожа на 100 и 373.

--------
Получается в 100-ом, 373-ом при обращение к любой переферии на шине АВР1, тормозится процесс обмена.
В 407-ом и 303, нет замедления.

Кто подскажет как прогнозировать данный процесс ?

Выигрыша нет. Например при тактовой 12 МГц потребление (по цифре) на полном ходу 7,4 мА, при остановленом 3,8 мА.
Если поднять частоту до 48 МГц, при этом уменьшить частоту шин для периферии на 4 (пропорционально увеличению частоты) и остановить ядро, получим 10,5 мА (на полном ходу 19,9 мА).
Начинает кушать больше всё, что весит на шине AHB.
В моем случае: 10,5 - 3,8 = 6,7 мА и (48 - 12 = 36 МГц) - это
1) DMA - 18,3 * 36 = 658 мкА
2) BusMatrix - 6,9 * 36 = 248 мкА
3) ABP2-Bridge - 4.2 * 36 = 151 мкА
4) ABP2-Bridge - 6.9 * 36 = 248 мкА
5) GPIO(A-E) - (12.2+11.9+4.3+12.0+4.4)*36 = 1612 мкА
суммарно 2,9 мА, оставшиеся 3,8 мА (105 мкА/МГц) прочие накладные расходы

Мне трудно судить про ST, я работаю в основном с NXP ядрами.
Но недавно у меня была похожая проблема при переносе кода с LPC1778 на более ранний LPC1758.
Начинало сбоить DMA<->SSP, хотя на LPC1778 всё прекрасно работало под длительными тяжёлыми тестами и периферия SSP и GPDMA в обоих контроллерах очень похожа.
На более низких скоростях (при снижении до единиц МГц) начинало работать, но хотелось как на LPC1778 - 20-30МГц по SSP.
Да - на LPC1778 я ещё ставил приоритет доступа к шине для GPDMA выше чем для CPU (там есть соотв. регистр), но на LPC1758 такого регистра нет
Так вот - помогло отключение пакетного режима DMA для LPC1758. Код остался тем же, но на LPC1778 используется пакетный режим, а на LPC1758 - не пакетный.
В чём разница я так и не понял, но теперь все тесты проходят нормально на самых высоких скоростях.
Да - у SSP-портов на LPC есть небольшое FIFO - вроде 8 слов насколько помню. Может оно помогает.
На контроллерах ST почему-то FIFO в периферии не любят

В вашем ST нету регистра управляющего приоритетами доступа к шине для разных устройств?

PS: А зачем кста так часто дёргать сторожевик?

Да, есть 4-е уровня приоритета для ПДП, но у меня он и так самый высокий стоит.

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

Я имею в виду не приоритеты каналов DMA, а приоритеты разных bus-masters (CPU I-Code bus, CPU D-Code bus, System bus, GPDMA bus, ...). У вас задача - чтобы приоритет доступа к шине для DMA был выше чем у шин CPU.
Вообще не понимаю разработчиков ядра Cortex - почему у процессора приоритет доступа (по дефолту) выше чем у DMA??? С этим часто бывают проблемы. На DSP C5502 у меня тоже с этим была проблема.
Имхо - должно быть наоборот. Везде где можно ставлю приоритет DMA выше чем у CPU.
Если интересно как сделано в LPC1778, можете глянуть раздел "2.5 AHB arbitration" юзермануала (UM10470.pdf). Там расписаны все bus-master-ы с приоритетами.

В STM-ках приоритет Bus master-ов не контролируется, Round Robin и точка. По крайней мере так говорит мануал.

Поставте в while несколько __nop(). Дайте DMA немножко больше тактов на передачу данных. Может все и будет нормально, если перефирию слишком часто не дергать. Ну так просто для интересу.
К стате, чего Вы к таким скоростям ADC привязались? Сигма дельта, который Вы хотите на таких скоростях не работает.

Дело, в том, что при любом обращении (хоть в цикле с нопами, хоть без) происходит задерка обмена, что приводит к изменению частоты дискретизации.
Конечно, чем реже обращения тем меньше вклад.

Возможности АЦП я прекрасно осознаю, да и не писал я, что мне нужно выжать из сигма-дельта 400 кГц.

Я говорил, о комбинации высокоскоростного преобразования 400 кГц (12 бит) и низкоскоростного, но с высоким разрешением 16 бит. А это доступно, только в STM32F373 (383).

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