Вопрос может показаться нелепым, но я на нем застрял.
Если между сеансами передачи данных организовать хотя бы небольшую задержку, то проблем никаких нет. Но если по окончании одного сеанса необходимо тут же начать новый, то второй почему-то зависает. Сразу приходит мысль о том, что по окончании первого сеанса был некорректно закрыт канал, но ни один из вариантов не увенчался успехом. За основу был взят алгоритм из даташита UM10360. LPC17xx. User manual:



Но всевозможные очистки очереди запросов прерываний (DMACINTTCCLEAR), отключения DMA для UART'a (U1FCR), отключения каналов DMA (DMACCONFIGURATION = 0) и прочие не помогли.

На всякий случай приведу один из вариантов кода инициализации канала DMA:



Однако мне интересно прежде всего, как Вы инициализируете и заканчиваете организацию передачи по UART'у через DMA. В частности, какие регистры и в какой последовательности при этом задействуете, а какие инициализируете в начале программы и не трогаете при повторении инициализации очередного сеанса.
Ни в даташите, ни в интернете, ни в примерах ИАР'а я не нашел однозначного ответа. В частности, из даташита не понятно, для чего нужны регистры, указывающие состояние передачи до маскирования (DMA Raw Error Interrupt Status register и DMA Raw Terminal Count Status register). Ведь мы маскируем прерывания еще до начала сеанса и какая может быть передача до этого момента?

В качестве обработчика прерываний я использую обработчик из примера.


Вроде бы этого достаточно для определения окончания передачи, но судя по тому, что между передачами требуется задержка, о которой я писал в начале, складывается ощущение, что на этом передача не заканчивается.
Хотелось бы узнать, есть ли здесь какие-то "подводные камни". Может кто поделится секретом?

Вы уверены что вам для UART нужен DMA?
для начала попробуйте настроить burst в 1 байт и ширину в 1 байт и для памяти и для уарта.

Да, DMA очень нужен. Потому и приходится биться с ним уже сколько времени.
А рекомендуемую настройку я уже применял:



Что касается burst size, то в даташите такое описание "indicates the number of transfers..." из которого не понятно, в каких единицах вычисляется это число - в байтах или битах. Впрочем, я перебрал все варианты этих параметров. Данные передаются лишь при SWidth=0, DWidth=0, SBSize=[3..7], DBSize=[3..7]. Но чему бы ни были равны SBSize и DBSize в указанных пределах, эффект не меняется при изменении этих параметров от 3 до 7 - передача идет, но между сеансами нужна задержка. При SBSize и DBSize равных 0, 1 и 2 данные не передаются вообще. Непонятно почему, ведь при SBSize и DBSize равных 0 по SPI нет проблем вообще.

Сообщение отредактировал sambotey - Sep 9 2011, 04:57

что непонятного - в пересылках, т.е. и не в битах и не в байтах, а в еденицах пересылки, которые вы задали в ширине шины.
А UART правильно настроен, там же надо trigger level у фифо в соотв. с барстом подбирать.

KRS, спасибо за подсказки. Сейчас пробую новые настройки уарт'а.

А интересно, возможна ли корректная работа DMА при разных значениях SBSize и DBSize в DMACC0CONTROL? Вроде бы нежелательно, чтобы эти значения отличались друг от друга, но зачем тогда было вводит два разных параметра? Достаточно было ввести один "BSize", который применялся бы и к источнику, и к приемнику.

Увы, пока безрезультатно.

Изначально, у меня были такие настройки UART'a:


Как видно, RX Trigger Level (в U1FCR) = 0, т.е. UART1 FIFO = 1 байт, что не подходило к моему burst size, который был равен 32 байта (SBSize=DBSize=5). Однако все работало


Как я понял, требуется, чтобы "RX Trigger Level" и "burst size" были равны. Однако это не принесло ничего нового.

Сейчас читаю документацию архитектуры АРМ, есть ряд деталей, которых я не нашел в даташите от NXP. В частности,


А у NXP прямо это не указывается.

Возможно конечно! DMA должен сам перепаковать и т.п. у него же свой фифо есть!
Еще можно попробовать flow controller ом назначить UART (хотя у nxp в даташите это reserved)

Увы, так я от необходимости задержки между сеансами и не избавился... В итоге, отложил эту проблему. Этот обмен данными выполняется однократно лишь в начале моей программы (этап инициализации), потому, по большому счету, все же не критично. Я так долго занимался этой проблемой, потому что мне казалось, что она тесно связана с действительно критичной проблемой, описанной мною в этом топике. Ее решением оказались следующие настройки:
UART: U1FCR = 0xCF
DMA: SBSize = DBSize = 0

Хотя и тут не обошлось без "танцев с бубнами", потому что мой этап инициализации программы при burst size = 0 уже не работает, ему burst size нужне не менее 3 (т.е., учитывая, что одна передача содержит 14 байт (U1FCR=0xCF), burst size = 3 означает передачу 16*14=224 байта, хотя у меня происходит обмен данными по 6 байт. Или я ошибаюсь в расчетах?)

Парадокс... Надеюсь, найду время попозже вернуться к нему.

Кстати, вышеприведенные настройки все же не приводят к желаемой скорости обмена данными, но работает более-менее стабильно. А вот желаемую скорость я смог получить при SBSize = DBSize = 7, и SWidth = 2 (32байта), но вот работа была нестабильной - через несколько сеансов не могу дождаться ответа от периферии.

KRS, спасибо большое за помощь.

В таком случае DMA не нужен, FIFO более чем достаточно!
Честно говоря вообще сомнительно использование DMA c UART.

DMA к UARTу особенно с переменным числом байтов в пакете проблематично цеплять, а у NXP судя по описанию он вообще криво подцеплен - там же только Burst Request подцеплен. А еще в описании UART таймаут тоже генерирует запрос к DMA, а т.к. подцеплен только барст то сколько байт по таймауту выгребет неизвестно если burst > 1. По идее таймаут к last линии должен быть подключен и flow контроллером должен быть UART но NXP данную конфигурацию не поддерживает!

Обмен по 6 байт происходит лишь периодически, на этапах инициализации периферии и квитирования. Между этими этапами происходит активный обмен данными по 512 байт. А DMA я решил использовать постоянно, чтобы не переключаться все время между ФИФО и ДМА.
Но вот чего я никак не могу понять, так это разницы между регистрами "DMA Interrupt Terminal Count Request Status register" и "DMA Raw Terminal Count Status register". По даташиту вся разница заключается в том, что первый сигнализирует об успешном окончании передачи ПОСЛЕ МАСКИРОВАНИЯ, а второй - ДО МАСКИРОВАНИЯ. Какое маскирование здесь имеется ввиду? То, наличие или отсутствие которого мы определяем 15м битом регистра конфигурации DMACCхCONFIGURATION? Но ведь до задания этого регистра еще не происходит никакой передачи данных. Да и в своей программе я обнаружил странную вещь: передача данных еще не завершилась, а бит в регистре "DMA Interrupt Terminal Count Request Status register" уже устанавливается.

А что Вам непонятного? В регистре GPDMA_RAW_INT_TCSTAT устанавливается бит соответствующего канала после завершения передачи, если выставлен 31 бит в регистре GPDMA_CHX_CTRL (не зависимо от бита 15 в регистре GPDMA_CHX_CFG).

Понятно, что он выставляется. Мне не понятно ОТЛИЧИЕ регистра GPDMA_RAW_INT_TCSTAT от GPDMA_INT_TCSTAT(надеюсь, верно написал название второго регистра, т.к. не знаю, в каких терминах Вы написали их названия). Ведь и в регистре GPDMA_INT_TCSTAT также выставляется бит соответствующего канала после завершения передачи.

В регистре GPDMA_INT_TCSTAT бит выставляется только в том случаи, если разрешены прерывания в GPDMA_CHX_CFG.
Проще говоря GPDMA_RAW_INT_TCSTAT используется тогда, когда отказываются от прерываний и завершение передачи определяют методом опроса.

ЗЫ Меня вот удивило, что копирование памяти (из sdram в sdram) по DMA выходит дольше, чем использование memcpy...