Здравствуйте, коллеги.

Не побеждается ADC3.

Имеем:
- STM32F103VC на 24MHz (не 72 для уменьшения потребления, т.к. есть back up на аккумуляторе),
- ADC3 в режиме сканирования трех каналов (11, 12 и 13), ADC тактируется 12MHz.
- естественно DMA2, канал 5, который складывает оцифрованное в буфер U16 длиной 32 триплета - всего 96 слов; таких буферов, конечно, два: один заполняем, из другого читаем.
- таймер 8, который с частотой 100Hz (замеряно) пихает ADC3 своим событием обновления (TRGO).
- прерывание от завершения передач DMA (по флагу TC), которое устанавливает флаг готовности буфера, переключает буферы и перегружает DMA канал.

В принципе, вся кухня работает. Но.
После рестарта может случиться, что данные оказываются смещенными в буфере: например, на месте канала 11 будут данные из канала 12, на месте 12 - из 13, ну а на месте 13 - из 11. Может случиться и сдвиг более дальнего порядка - в 11 - из 13, ну и так далее, по кругу. Причем этот сдвиг случается один раз при старте системы, а в процессе работы все остается фиксированно, без перескоков.

Я тщательно проанализировал последовательность инициализации и попытался в прерывании DMA сбрасывать бит STRT в ADC3->SR и "прочищать" ADC3->DR (чтением) перед тем как перегрузить DMA. Тем не менее в прерывании я мог всегда(!) поймать ситуацию при самом _первом_ вхождении, когда после перегрузки DMA его счетчик тут же уменьшался на единицу, словно ADC3 припрятал запрос к DMA несмотря на "прочистку".
Последнее, что я сделал, - поднял приоритет DMA до "kill 'em all", а в прерывании - выключал бит DMA в ADC3->CR2, делал прочистку ADC и перегрузку DMA и включал ADC3->CR2 снова. На моей плате это вроде привело к успеху (счетчик DMA не уменьшался сразу), а вот у коллеги - нет.

Идеи?
Заранее благодарен.

Еще бы таймер "прочистить", чтобы события лишнего не генерил.

Ну... это вряд ли поможет. Таймер стучит каждые 10мс - вечность. Оцифровка всех трех каналов занимает около 3х 85 циклов = 255 или ~22мкс (при 12MHz ADC). Пусть это был последний триплет, и сработало прерывание DMA. Прерывание из трех строк не зависает на 10мс.

П.С. очистка таймера (каким образом?) наверняка приведет к изменению периода, то есть к шуму квантизации... Не кошерно как-то...

вот недавно сам столкнулся с таким же. Нашел решение на этом же форуме. А именно сбрасывать регулярные каналы. И все заработал
вот мой код

По таймеру все 3 канала преобразуются, значит? Группа.
8-битовые? А по 16 битов, может, без сбоев пойдет?

Группа.

Собственно, 12-битовые (разрядность ADC), выровненные влево до 16-ти бит (разрядность DR), DMA забирает как U16.

Значит на момент старта DMA АЦП уже успело сделать два измерения и результат первого для DMA оказался потерян. В какой последовательности вы запускаете всю эту кухню? По моим понятиям надо делать так:
1) таймер остановлен
2) Настраиваем АЦП, сбрасываем все готовности, которые могли остаться от предыдущей работы.
3) Настраиваем ПДП
4) запускаем таймер.

Я тоже так пробую делать (сброс бита DMA в CR2 и STRT в SR, чтение DR три раза) за исключением сброса количества преобразований в SQR1, правда. Сейчас попробую и это, хотя на мой взгляд - как из пушки по воробьям.

Кстати, в Вашем коде нет собственно "взвода" ADC на следующую операцию. Опущено здесь для иллюстрации? Еще для упрощения можно делать ADC1->SR = ~(ADC_SR_STRT), без &=, т.к. регистр SR есть rc/w0 - тип: пишешь прямо 0 в сбрасываемый бит.



Ладно, цитатнём код.
Единократная инициализация:

Это объяснение для MIC_Control(true):

И самое интересное в прерывании:

В коде много функций, которые на самом деле макросы, но из имен ясно, что они делают. Думаю, последовательность ясна.

в принципе дальше в коде стоят

но вы не поверите. и без них работает, потому что ранее записано кол-во перобразований, осуществяемых через DMA и выставлено прерывание. А может быть это просто мистика, но оно работает

Ой, сложно как все...

Буферов два? Расположите их подряд. Пусть ПДП таскает в них данные в циклическом режиме. Без взяких перенастроек. "Пустил-забыл". ПДП дает два прерывания - "половину буфера заполнил" и "весь буфер запомнил". По первому флагу обрабатываем первый буфер, по второму - второй. В обработчике проверяем флаги ПДП, сбрасываем сработавший, запускаем обработку соответствующей половины "склеенного" буфера. Все. Больше ничего не трогаем.

Ваш ADC_ClearRegular() делает совсем не то, что вы хотели. Он может вычитать результат максимум только одного преобразования. А может и вообще ни одного не вычитать. Потому что DR хранит результат одного (последнего) преобразования, никакого буфера типа FIFO на несколько результатов там нет. Если бы мне понадобилась подобная функция, я бы в ней выбросил параметр cnt, проверял STRT и если он выставлен (преобразование началось) - дожидался EOC, после чего сбрасывал бы EOC чтением DR, а STRT - записью в него 0.

Хорошие идеи. Спасибо. И все же интересно, почему происходит сдвиг данных.

P.S.
Итак, я реализовал Вашу идею, все замечательно. Еще раз спасибо. И кажется, я обнаружил-таки, в чем была причина "лишних" неполных данных.
В доке написано, что повторное разрешение ADC (то есть, запись "1" на уже "1" в CR2.ADON) приводит к запуску преобразования:

Conversion starts when this bit holds a value of 1 and a 1 is written to it.

Тут же далее курсивом упомянуто, что если в этом регистре одновременно меняются и другие биты (например CR2.DMA), то запуск преобразования не происходит:

If any other bit in this register apart from ADON is changed at the same time, then
conversion is not triggered. This is to prevent triggering an erroneous conversion.

Так вот, враки это все! Этот "предохранитель" не работает, и преобразование запускается. Четко в отладчике видно. Тема для errata. Вот и получалось, что команда ADC_DMACmd(ADCx, DISABLE) запрещала передачу запросов в DMA, но запускала каждый раз преобразование. Оттуда и "лишние" данные и сдвиги.