|
|
  |
NXP LPC1778 GPDMA. Проблемы при паралеллельных DMA-транзакциях |
|
|
|
Aug 24 2012, 04:13
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Кто-нить работал на 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?
|
|
|
|
|
Aug 24 2012, 07:04
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Просто уникальный здесь форум! Почти два дня бился над проблемой, но как только написал здесь - сразу нашёл решение! В каждой паре 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: Может это кому-то поможет если кто столкнётся с аналогичной траблой.
|
|
|
|
|
Aug 30 2012, 05:24
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Похоже рано радовался  (( Вышеописанная проблема решилась, но всё равно перекрывающиеся DMA-транзакции работают нестабильно (если два SSP-канала работают по GPDMA). В какой-то момент времени при очередном наложении транзакций с двух SSP происходит сбой. Выражается это в порче передаваемых данных. Т.е. - читаю блоки данных по двум SSP с перекрытием по времени и в какой-то момент времени в одной из транзакций получаю искажённые данные, причём после этого не приходит прерывание завершения по более низкоприоритетному из работающих DMA-каналов. Такое ощущение, что более приоритетный DMA-канал перехватывает запрос от низкоприоритетного DMA-канала (от другого SSP) и выполняет его, передавая или принимая данные к чужому или от чужого SSP. Бред полный..... Кто-нить вообще работал на LPC17xx с перекрывающимися по времени GPDMA-транзакциями работающими с разной периферией? Именно _с_разной_, 2 DMA-канала для одного SSP (ввод/вывод) работают прекрасно. А вот когда их уже 4...... Перепробовал уже всё что возможно (частоты SSP, распределение GPDMA-каналов, управление SSEL(GPIO и автомат) и т.п.). И еррата молчит
|
|
|
|
|
Aug 30 2012, 08:15
|
Знающий
   
Группа: Свой
Сообщений: 549
Регистрация: 13-07-10
Из: Солнечногорск-7
Пользователь №: 58 414

|
Из Вашего описания совершенно невозможно понять, как именно программируются каналы и т.д.
ADD. Учитывая, что каналы с меньшими номерами имеют более высокий приоритет, а прерывания а применительно к SSP приём является вторичным по отношению к передаче (т.е. сначала необходимо начать передачу, чтобы пошёл приём), на приём должны работать более приоритетные каналы (скажем, 0 и 1), а на передачу -- менее приоритетные (к примеру, 6 и 7). В такой ситуации, когда у контроллеров SSP будут данные, они немедленно будут считываться из буферов SSP и записываться в память, а вот обратная операция -- передача из памяти в контроллер SSP -- будет выполняться лишь тогда, когда контроллер ПДП не занят обслуживанием считывания.
Сообщение отредактировал SII - Aug 30 2012, 08:21
|
|
|
|
|
Aug 30 2012, 10:18
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Цитата(SII @ Aug 30 2012, 14:15)  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 и почти миллион по другому. С перекрытием.
|
|
|
|
|
Aug 30 2012, 10:44
|
Знающий
   
Группа: Свой
Сообщений: 549
Регистрация: 13-07-10
Из: Солнечногорск-7
Пользователь №: 58 414

|
Цитата Для работы на полных 30МГц по одному SSP и 20МГц по другому SSP, пришлось отказаться от автоматического управления линией SSEL - похоже шина не успевала прокачивать данные для TX-канала и SSEL кратковременно обрывался (вследствие чего проходил сбой операции у DFLASH/FRAM микросхемы) Хм... А Вы уверены, что дело именно в частоте? Ведь, если склероз не изменяет, контроллер SSP при определённых установках кратковременно снимает SSEL между "символами" (байтами при побайтовом обмене). Может быть, проблема как раз в этом и её можно убрать, изменив настройку контроллера SSP?
|
|
|
|
|
Aug 31 2012, 20:37
|
Участник

Группа: Участник
Сообщений: 21
Регистрация: 18-06-06
Пользователь №: 18 144

|
Цитата(jcxz @ Aug 30 2012, 14:18)  объекты для LLI структур (у меня передачи связными списками) Поскольку Вы используете LLI, может подскажите: Возможно ли этот механизм использовать циклически? Т.е. имеется некоторый циклический буфер в памяти, из которого нужно при помощи DMA извлекать блок данных и записывать в 8 регистров периферии. Проблема в том, что адреса этих регистров находятся не последовательно, а в разнобой. Вроде LLI в этом может помочь, но я не совсем понимаю, как сделать автоматический инеремент адреса источника? Правда у меня LPC4300...
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|