[jcxz 231]

Кто-нить работал на LPC1778 с GPDMA параллельно по нескольким каналам (т.е. - одновременно с наложением по времени на разных каналах с разной периферией)?

Такая проблема:

Имеем перекрывающуюся по времени работу по двум SSP-каналам через GPDMA (4 канала - 2TX, 2RX).

Если транзакции по времени не перекрываются - всё работает нормально.

Если происходит наложение (любого типа - или при работающем первом SSP-канале происходит запуск 2-го или при работающем втором - запуск первого, ожидаемое завершение 1го раньше чем 2-го или наоборот - позже), то работа SSP для, которого используются DMA-каналы с меньшим номером завершается нормально (приходит end-interrupt), работа SSP который использует большие номера DMA-каналов останавливается (в битовом поле работающих DMA-каналов, тот канал (RX-канал), по которому ожидается приход события завершения, застревает навечно в состоянии "active"). Соответственно не приходит прерывание о завершении и в регистре DMA.IntTCStat == 0).

Если обменять используемые SSP-каналами DMA-каналы местами, то проблема начинается на другом SSP-канале - всегда отваливается тот, у которого номера используемых DMA-каналов меньше.

Т.е. - как будто любая активность по DMA-каналу с меньшим номером останавливает или целиком работу более старших каналов DMA или останавливает приход end-interrupt по старшим каналам.

 

Просмотрел еррату - там пусто на этот счёт.

Или может кто сталкивался с подобным на предыдущих LPC17xx?

[jcxz 231]

Просто уникальный здесь форум! Почти два дня бился над проблемой, но как только написал здесь - сразу нашёл решение!

В каждой паре RX/TX DMA-каналов поменял местами каналы для RX <-> TX - и всё заработало.

Т.е. раньше у меня было такое распределение каналов DMA:

enum {DMA_CH_fram_TX, DMA_CH_fram_RX, DMA_CH_dflash_TX, DMA_CH_dflash_RX};

поменял на:

enum {DMA_CH_fram_RX, DMA_CH_fram_TX, DMA_CH_dflash_RX, DMA_CH_dflash_TX};

Прерывание завершения транзакции по соотв. SSP у меня приходит для DMA_channel.RX. Получается, что когда DMA_channel.RX имеет больший номер (меньший приоритет?) чем DMA_channel.TX, то если параллельно запускается другая DMA-транзакция на другом SSP, происходит потеря завершения на 1-м SSP.

Обмен каналами между DMA_CH_fram и DMA_CH_dflash ни к чему не приводил - только вис другой канал. Как и просто смещение каналов на разные номера - всегда вис тот, у кого больше номера DMA-каналов.

Помогло только это - сделать RX-канал меньше номером, чем TX.....

 

PS: Может это кому-то поможет если кто столкнётся с аналогичной траблой.

[Axel 1]

Интересно, поскольку ситуация актуальная... Пытаюсь найти логику, но не получается. Это я ее не вижу, или это натуральный бубен?

[jcxz 231]

Похоже рано радовался :(((

Вышеописанная проблема решилась, но всё равно перекрывающиеся DMA-транзакции работают нестабильно (если два SSP-канала работают по GPDMA).

В какой-то момент времени при очередном наложении транзакций с двух SSP происходит сбой. Выражается это в порче передаваемых данных. Т.е. - читаю блоки данных по двум SSP с перекрытием по времени и в какой-то момент времени в одной из транзакций получаю искажённые данные, причём после этого не приходит прерывание завершения по более низкоприоритетному из работающих DMA-каналов.

Такое ощущение, что более приоритетный DMA-канал перехватывает запрос от низкоприоритетного DMA-канала (от другого SSP) и выполняет его, передавая или принимая данные к чужому или от чужого SSP.

Бред полный.....

 

Кто-нить вообще работал на LPC17xx с перекрывающимися по времени GPDMA-транзакциями работающими с разной периферией?

Именно _с_разной_, 2 DMA-канала для одного SSP (ввод/вывод) работают прекрасно. А вот когда их уже 4......

 

Перепробовал уже всё что возможно (частоты SSP, распределение GPDMA-каналов, управление SSEL(GPIO и автомат) и т.п.). И еррата молчит

[SII 0]

Из Вашего описания совершенно невозможно понять, как именно программируются каналы и т.д.

 

ADD. Учитывая, что каналы с меньшими номерами имеют более высокий приоритет, а прерывания а применительно к SSP приём является вторичным по отношению к передаче (т.е. сначала необходимо начать передачу, чтобы пошёл приём), на приём должны работать более приоритетные каналы (скажем, 0 и 1), а на передачу -- менее приоритетные (к примеру, 6 и 7). В такой ситуации, когда у контроллеров SSP будут данные, они немедленно будут считываться из буферов SSP и записываться в память, а вот обратная операция -- передача из памяти в контроллер SSP -- будет выполняться лишь тогда, когда контроллер ПДП не занят обслуживанием считывания.

Изменено 30 августа, 2012 пользователем SII

[jcxz 231]

ADD. Учитывая, что каналы с меньшими номерами имеют более высокий приоритет, а прерывания а применительно к SSP приём является вторичным по отношению к передаче (т.е. сначала необходимо начать передачу, чтобы пошёл приём), на приём должны работать более приоритетные каналы (скажем, 0 и 1), а на передачу -- менее приоритетные (к примеру, 6 и 7).

Да, согласен с Вами. Сейчас у меня так и сделано.

 

Всё - разобрался в проблеме. Баг был у меня ;)

Когда копировал функцию запуска DMA-транзакции одного SSP и переделывал её для другого SSP, забыл для второго SSP сделать свои объекты для LLI структур (у меня передачи связными списками), соответственно они и портились :)

После этого заработало всё, но на маленькой скорости.

Для работы на полных 30МГц по одному SSP и 20МГц по другому SSP, пришлось отказаться от автоматического управления линией SSEL - похоже шина не успевала прокачивать данные для TX-канала и SSEL кратковременно обрывался (вследствие чего проходил сбой операции у DFLASH/FRAM микросхемы). Хотя для GPDMA-контроллера выставил максимальный приоритет доступа к шине в регистре арбитража AHB (выше чем у CPU) - это не помогало.

Уже всё пашет - тест показывает 3.5млн транзакций по одному SSP и почти миллион по другому. С перекрытием. :)

[SII 0]

Для работы на полных 30МГц по одному SSP и 20МГц по другому SSP, пришлось отказаться от автоматического управления линией SSEL - похоже шина не успевала прокачивать данные для TX-канала и SSEL кратковременно обрывался (вследствие чего проходил сбой операции у DFLASH/FRAM микросхемы)

 

Хм... А Вы уверены, что дело именно в частоте? Ведь, если склероз не изменяет, контроллер SSP при определённых установках кратковременно снимает SSEL между "символами" (байтами при побайтовом обмене). Может быть, проблема как раз в этом и её можно убрать, изменив настройку контроллера SSP?

[jcxz 231]

Почему тогда всё прекрасно работает (на любых частотах вплоть до максимальных) если нет перекрытия по времени работы двух SSP?

Проверил несколько миллионов транзакций. При перекрытии и частотах выше какого-то порога (15/12МГц или 20/6МГц) сбой появляется уже в первой тысяче транзакций.

[Ant. 0]

объекты для LLI структур (у меня передачи связными списками)

 

Поскольку Вы используете LLI, может подскажите:

Возможно ли этот механизм использовать циклически?

Т.е. имеется некоторый циклический буфер в памяти, из которого нужно при помощи DMA извлекать блок данных и записывать в 8 регистров периферии. Проблема в том, что адреса этих регистров находятся не последовательно, а в разнобой. Вроде LLI в этом может помочь, но я не совсем понимаю, как сделать автоматический инеремент адреса источника?

 

Правда у меня LPC4300...