Может кто сталкивался.

SPI передает и принимает с использованием DMA.
Очевидно, что для приема надо передавать хоть что-то (суть SPI), что я делаю с помощью двух каналов DMA:
- каналы приема (RX) и передачи (TX) взводятся, при этом в оба загружаются, естественно, одинаковые счетчики.
- толкается DMA TX.
- ожидается завершение DMA RX.

Так вот, иногда (не воспроизводимо и спорадически) из цикла ожидания можно и не выйти, а если прервать, то наблюдается следующее состояние:
- канал TX выплюнул всё (его счетчик 0).
- канал RX еще ждет, т.к. его счетчик равен 1,
- в SPI установлен бит переполнения по приему.

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

Частота процессора: от 24 до 48MHz (переключаю выше, когда подсоединяется USB), частота SPI1 12MHz или 24MHz соответственно. SPI работает с SPI flash, которая может от 25MHz и выше.

Есть идеи?

А на <12MHZ работает?

А на какой частоте работает ДМА выясняли?

Когда занимался с таймером и DMA обнаружил, что от момента старта DMA до момента DMA-транзакции проходит более 12 тактов.
Этот момент даже где-то описан в документации.
Думаю, проблема в старте DMA, когда приходит первый байт, запускается DMA, но сама DMA-транзакция наступает спустя 12 тактов.
За это время уже успувает придти второй байт.
С позиций передатчика выглядит так: первый байт отправляется с паузой 12 тактов, а второй и последующие без пауз.

Я ее не мерял, но судя по схеме в документации (стр. 90 Doc ID 13902 Rev 12 для STM32F10x) они тактируются частотой AHB, то есть ядра. В моем случае это 24 или 48MHz.



Имеется ввиду SPI? Нет, не понижал. Однако наверняка будет работать стабильней, т.к. частота ошибки растет с увеличением частоты SPI (как я писал, SPI у меня - половина такта процессора). Но понижение частоты - не решение, пока не разобрался с первопричиной.

Думаю, adnega здесь привел самую разумную гипотезу с первоначальной задержкой DMA. Потому и отличие всего в один байт в итоге. Ведь и готовность приема возникает на один SPI такт позже, чем готовность передатчика. То есть, SPI уже начала передачу второго байта, а флаг RXNE только взводится. То есть, при 24MHz SPI остается всего 292нс (7 битов) на то, чтобы вычитать принятый байт, пока он не затерся новым. У меня в системе есть еще другой DMA, который обслуживает ADC. Он тоже на шину лезет, хотя приоритет его и ниже читающего из SPI. Но ведь и на арбитраж время нужно...

Вот походил, подумал о work around. Если изначально загрузить в TX DMA счетчик 1, разрешить прерывание по TC, пихнуть DMA и в прерывании дозагрузить счетчик N-1, то этим можно ввести паузу между первым и последующими байтами.

Ага, щаз. Сколько пройдет тактов при передаче байта? Правильно, 16.
Т.е. 4 такта на собсна fetching все-же есть. А пробовали заглушить АЦП-DMA?
ЗЫ я имею ввиду - если толкать DMA таким образом

Я для приема по spi через dma просто перевожу spi в режим приемника. тогда на sclk spi идут постоянные клоки. Соответственно нет необходимости в передаче по spi. Здесь в какой то ветке про это писали. По завершению приема надо spi переводить в режим приемо-передатчика.

Чаще всего 12 тактов, но иногда и больше.
Делал светодиодное табло с динамической индикацией: видеопамять с помощью таймеров (каскадное соединение), SPI и DMA передавалась
в светодиодную панель. И вроде все хорошо и согласуется с теорией, но иногда были не то проблескивания, не то сдвиги столбцов и строк...
Очень редко, очень неуловимо, но когда понял что к чему, оказалось что есть задержка 12 тактов, но иногда (и именно в этих случаях были проблемы) больше 12. DMA был настроен на SPI_TX. Необходимые стробы формировались таймером. Задержка в первом байте на 12 тактов могла означать сдвиг на фиксированное число точек (в моем случае на 1) и легко фиксилось программно, но в случаях задержки более 12 тактов - были сбои. DMA с наивысшим приоритетом и использовался только канал SPI_TX.
Недано на скорую руку делал титровалку (наложение текста на видеосигнал) на STM32F373 при скорости SPI близкой к частоте ядра опять те же
проблемы. Увеличил BR для SPI (да горизонтальное разрешение упало, но мне не критично) и артефакты пропали.

Добавлено:
Да, совсем забыл - очень помогает уйти от 8 битных посылок SPI к 16 битным.

Возникает, однако, вопрос, как остановить вовремя прием? Рекомендация на стр. 693 " Then wait for one SPI clock cycle (using a software loop) before disabling the SPI (SPE=0)" в части программной задержки звучит вообще просто дико для системы со множеством прерываний и DMA...


Мне не поможет, т.к. количество байт для считывания может быть и нечетным.

P.S. как я и намеревался, замутил тему с передачей одного байта, а затем перегрузку N-1 байтов. Похоже, проблема ушла. Предложение _Pasha толкнуть процесс первый раз синхронно также очень удачен и прост - удивляюсь, как это не пришло в голову мне самому...

А это как, на таймерах видеопамять ?

Я останавливаю прием в прерывании от dma.

А успеет?

Почему же?
Если данных четное число, то просто отправляем их 16 битными посылками.
Если нечетное, то отправляем один байт, дожидаемся приема. Затем отправляем четное количество данных.
Ожидание приема можно совместить с настройкой DMA, т.е. отправляете байт, настраиваете DMA, ждете флаг приема
(а с учетом Вашей скорости SPI он уже закончится), отправляете данные через DMA 16-битными словами.


Обычно светодиодное табло - это длинный/длинные сдвиговые регистры. В случае динамической индикации все еще интереснее.
Так вот, на таймерах STM можно сделать отправку видеоданных через SPI и DMA с формированием всех необходимых
строб-сигналов. Т.е. остается только периодически вызывать refresh(), в которой инициализируется таймеры, DMA и SPI
- все остальное делается аппаратно, причем не для одной строки, а целиком для всей видеопамяти. Нагрузка на CPU 0%.

В моем случае глюков не замечалось. обшаюсь через spi с ad7714 и at45db + usb-com. Возможно в ваших условиях и не заработает. Надо проверять/

а при 16 битной посылке байты местами поменяются... сам недавно столкнулся и тема на форуме была.

обычно, в таких случаях, делают 2 буфера приёма равные по величине буферу передачи. таким образом когда первый приёмный буфер переполняется включается второй и запись продолжается в него. в данной ситуации не нужно делать стоп ДМА приёма и, возможно, терять данные.
ещё один нюанс: приёмные буфера нужно настраивать ДО передающих(они в свою очередь должны быть выключены) и уж тем более ДО старта их работы.
судя по даташиту такая реализация без участи АЛУ невозможна на данном камешке. в ДМА нет возможности указать на адрес в памяти куда пихать данные в случае переполнения буфера (или я не прав?)
есть вопрос: почему для передачи принятых данных используется 4 канал ДМА1? разве он заточен под запросы для SPI а не для SDIO?
судя по даташиту, (хоть и не самому свежему), лучше брать 2 для RX и 3 для TX каналы для этого дела (стр. 188). сильно не вникал в даташит, но первые впечатления не очень о камушке. на мой взгляд AT91SAM7 получше в этом плане будет, хотя он и уступает в количестве переиферии... ИМХО...

скромный вопрос: Вы слышали что-нибудь о big-endian и little-endian?