jcxz 234 24 августа, 2012 Опубликовано 24 августа, 2012 · Жалоба Кто-нить работал на 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 234 24 августа, 2012 Опубликовано 24 августа, 2012 · Жалоба Просто уникальный здесь форум! Почти два дня бился над проблемой, но как только написал здесь - сразу нашёл решение! В каждой паре 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 25 августа, 2012 Опубликовано 25 августа, 2012 · Жалоба Интересно, поскольку ситуация актуальная... Пытаюсь найти логику, но не получается. Это я ее не вижу, или это натуральный бубен? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 30 августа, 2012 Опубликовано 30 августа, 2012 · Жалоба Похоже рано радовался :((( Вышеописанная проблема решилась, но всё равно перекрывающиеся DMA-транзакции работают нестабильно (если два SSP-канала работают по GPDMA). В какой-то момент времени при очередном наложении транзакций с двух SSP происходит сбой. Выражается это в порче передаваемых данных. Т.е. - читаю блоки данных по двум SSP с перекрытием по времени и в какой-то момент времени в одной из транзакций получаю искажённые данные, причём после этого не приходит прерывание завершения по более низкоприоритетному из работающих DMA-каналов. Такое ощущение, что более приоритетный DMA-канал перехватывает запрос от низкоприоритетного DMA-канала (от другого SSP) и выполняет его, передавая или принимая данные к чужому или от чужого SSP. Бред полный..... Кто-нить вообще работал на LPC17xx с перекрывающимися по времени GPDMA-транзакциями работающими с разной периферией? Именно _с_разной_, 2 DMA-канала для одного SSP (ввод/вывод) работают прекрасно. А вот когда их уже 4...... Перепробовал уже всё что возможно (частоты SSP, распределение GPDMA-каналов, управление SSEL(GPIO и автомат) и т.п.). И еррата молчит Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SII 0 30 августа, 2012 Опубликовано 30 августа, 2012 (изменено) · Жалоба Из Вашего описания совершенно невозможно понять, как именно программируются каналы и т.д. ADD. Учитывая, что каналы с меньшими номерами имеют более высокий приоритет, а прерывания а применительно к SSP приём является вторичным по отношению к передаче (т.е. сначала необходимо начать передачу, чтобы пошёл приём), на приём должны работать более приоритетные каналы (скажем, 0 и 1), а на передачу -- менее приоритетные (к примеру, 6 и 7). В такой ситуации, когда у контроллеров SSP будут данные, они немедленно будут считываться из буферов SSP и записываться в память, а вот обратная операция -- передача из памяти в контроллер SSP -- будет выполняться лишь тогда, когда контроллер ПДП не занят обслуживанием считывания. Изменено 30 августа, 2012 пользователем SII Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 30 августа, 2012 Опубликовано 30 августа, 2012 · Жалоба 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 августа, 2012 Опубликовано 30 августа, 2012 · Жалоба Для работы на полных 30МГц по одному SSP и 20МГц по другому SSP, пришлось отказаться от автоматического управления линией SSEL - похоже шина не успевала прокачивать данные для TX-канала и SSEL кратковременно обрывался (вследствие чего проходил сбой операции у DFLASH/FRAM микросхемы) Хм... А Вы уверены, что дело именно в частоте? Ведь, если склероз не изменяет, контроллер SSP при определённых установках кратковременно снимает SSEL между "символами" (байтами при побайтовом обмене). Может быть, проблема как раз в этом и её можно убрать, изменив настройку контроллера SSP? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 31 августа, 2012 Опубликовано 31 августа, 2012 · Жалоба Почему тогда всё прекрасно работает (на любых частотах вплоть до максимальных) если нет перекрытия по времени работы двух SSP? Проверил несколько миллионов транзакций. При перекрытии и частотах выше какого-то порога (15/12МГц или 20/6МГц) сбой появляется уже в первой тысяче транзакций. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ant. 0 31 августа, 2012 Опубликовано 31 августа, 2012 · Жалоба объекты для LLI структур (у меня передачи связными списками) Поскольку Вы используете LLI, может подскажите: Возможно ли этот механизм использовать циклически? Т.е. имеется некоторый циклический буфер в памяти, из которого нужно при помощи DMA извлекать блок данных и записывать в 8 регистров периферии. Проблема в том, что адреса этих регистров находятся не последовательно, а в разнобой. Вроде LLI в этом может помочь, но я не совсем понимаю, как сделать автоматический инеремент адреса источника? Правда у меня LPC4300... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться