Всем привет!

Есть такая проблемка на LPC1768 настроен SSP в режиме slave
входные данные при помощи DMA перегружаться в буфер 1024 байта.

если на вход напихать данных так штук 2000, то буфер переполняется, для сброса этого дела
я
1. выключаю DMA каналы,
2. дожидаюсь что пропал битик включения канала
3. вычитываю буфер FIFO SSP
4. переинициализирую DMA канал

и мне приходит последний байт, хоть убейся об него...

Такая же переинициализация в середине обмена - все хорошо, а по переполнению вот такая фигня.

Кто сталкивался, как победить?

Как почистить кроме входного еще и выходной SPP FIFO?

Что-то у Вас неправильно с процессом останова SSP+DMA.
Как Вы DMA выключаете? Просто запрещаете его работу?
Учитываете, что в DMA тоже есть FIFO? И если просто сделать запрет каналу, то данные там могут остаться.
Да и останов у Вас наверное неверный раз в выходном FIFO SSP данные могут остаться. Не должно так быть.

Останов по переполнению это значит, что:
Вы запрограммировали DMA (два канала: TX и RX) на передачу/приём с SSP некоторого фиксированного блока (размер TX == размеру RX (или кратны)).
И останов нужно делать только в прерывании завершения этого блока (или если блоки кратны - по завершении наибольшего (когда оба блока завершены)).
А если Вы делаете стоп посередине (зачем-то), то сами себе злобный буратино. Тогда должны позаботиться об опустошении всех FIFO перед след. операцией.

Раз у Вас SSP-slave, то ещё наверное нужно после останова DMA, ожидания завершения активности SSP и запрета SSP, вычитать RX-FIFO SSP. Он вроде не сбрасывается при запрете SSP.
А в TX-SSP у Вас и не должно остаться данных, если как я описал будете работать.

Не будет...
Да сейчас я себе злобный буратино, но жизнь то она многообразная...
Интересно я один делаю тесты на устойчивость?

SSP-Slave, значит выдает данные только по клоку мастера. Вы начали ответный обмен, показали что у вас есть данные, положили их в буфер, настроили ДМА, тот их радостно набил в FIFO свое и SSP, все готовы, на низком старте. А тут мастер взял и сдох, или перегрузился, или передумал... дальше что?

Я фифо DMA смогу почистить, выключил канал, включил и оно якобы чистое (правда почему то в приемном 1 байт застревает, в ответном не знаю, не проверял). А вот фифо SSP никак выходное не почистишь...

Добавил требование после сброса обмена клочить на то чтобы выдавилось FIFO SSP

В обратную сторону, данные переменной длины, но никто не застрахован от того что во время инициализации или просто по дури мастер не напихает левых данных на вход. У меня входной буфер 1Кбайт, это больше нормальной посылки, DMA в штатном режиме никогда до конца его не набивает, и прерывания никакого нет на окончание посылки. Работа идет с принятой частью.

Но вот теперь у нас появился злобный мастер буратина, который взял и выдал свой клок на ногу клока SSP, что дальше? У нас весь буфер забит под завязку, данные не обработаются, не сойдется контрольная сумма и прочая байда, чтобы не было проблем DMA настроено на выключение после приема 1024 байт, и в целом оно это делает.
Но по какой-то неведомой причине после того как я его заново включаю оно мне досылает последний байт, хоть убейся об него...

То есть я так понимаю почему то не снимается бит запроса канала DMA от SSP, и как только тот включается, он сразу получает запрос и выполняет его, а в приемнике SSP лежит последний принятый байт. И вот это я не смог побороть.







------------------------------------------------------------------------------------------
Провел серию проверок, по ходу дела DMA на выход не набивает FIFO SSP целиком, а кладет по одному байтику по мере опустошения, по сигналы FIFO - пусто. Но 1 байт при обрыве обмена все же останется, это надо учитывать.

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

---------------------------------------------------------------------------------------------------------------------
Ну вот, если правильно локализовать проблему становиться понятно как с ней бороться.

Зависали не FIFO и не буферы, зависал сигнал запроса от SSP.

Правильный порядок сброса каналов
1. Отключаем каналы DMA
2. Ждем их выключения
3. Отключаем DMA на SSP
4. сбрасываем входное FIFO SSP (читаем 8 раз)
5. сбрасываем выходное FIFO SSP (тут надо мастеру вычитать 1 возможно оставшийся байт или перейти в мастер режим и выдавить его)
6. перенастраиваем каналы DMA
7. дожидаемся включения
8. включаем DMA в SSP

у меня оставшийся байт погоды не делает при начале обмена он пропадет, если же он мешает, то после это процедуры можно мастером его считать, но так чтобы не запустить новую передачу обратно и еще раз сбросить. А можно перевести SSP в режим мастера и выдавить все байты наружу, а потом вернуть в слейв режим.

Но в любом случае, такой перезапуск приводит систему в начальное состояние (с точностью до байта в выходном FIFO) и ура!

Вы уверены?
Вообще-то у канала нет бита выключения, а только бит разрешения. И я сильно сомневаюсь, что при его запрещении, FIFO канала очистится. Вроде в UM это явно не указано.
Оно даже может не очищаться при подаче аппаратного RESET на процессор.


Вы сначала выясните где именно у вас байты остаются в каком FIFO - SSP или DMA. Может оба нужно выфлушивать.
Странно у вас как-то система построена - часть может вдруг сброситься (мастер), а остальная - нет. Может это надо как-то исправить? Сброс общий для обоих сделать.


Не понимаю - в чём тут проблема?
Программируете DMA на какой-то блок данных. Даже пускай не зная сколько передаст мастер. Когда этот блок закончится - придёт прерывание, в нём запрограммируете на след. блок, пока он заполняется - разгребаете предыдущий.
Если у Вас перегрузился мастер, то заводИте ещё реакцию на прерывание от снятия сигнала CS и в этом ISR чистите (выфлушиваете) FIFO. SSP на это время надо наверное перевести в режим мастер
(с отключенными пинами). А для мастера требование - задержка от момента старта ПО до ближайшей транзакции по SSP достаточная для очистки.

уверен из юзер мануала

бит называется E - channel enable, не знаю как это понятие перевести иначе как включение канала

также не знаю как перевести иначе следующее высказывание из описания

канал выключается - данные в фифо теряются.


как почистить фифо ДМА мы уже разобрались строкой выше. Теперь надо понять как работает ваще ДМА.
При запуске оно набивает 4 слова в свое фифо, и одно слово кладет в FIFO SSP. SSP - отдаст его только по чипселекту и клоку, а на его место сразу ляжет новое слово из ДМА. Если при запущенном обмене его прервать, больше клоков не будет, тогда одно слово останется в FIFO SSP, очистить его иначе как считать мастером невозможно. Кстати при не ДМА обмене там может быть до 8 слов.



Система как система из 3 автономных устройств, на одном из них мастере даже линукс стоит. Общий сброс - перегрузка линукса не круто, там могут и задачу снять, и провод оторвать, и загрузиться они могут в произвольном порядке, гораздо правильнее сделать восстанавливаемую систему, чем надеяться что один раз правильно ее включив она будет работать до выключения.



Какой размер блока? Сообщения переменной длинны, реагировать на них надо как только так сразу. Настроить на минимальную длину и постоянно ворошить блоки, зачем?Сейчас для ДМА выделен буфер 1КБайт, оно туда кладет данные спокойно, а проц этот буфер время от времени проверяет, и если там есть целое сообщение обрабатывает.



А вот тут вас ждут 2 разочарования.
1 - нет такого прерывания, а в добавок этот чипселект может быть на 1 порту, там нет даже GPIO прерывания (они только на 0 и 2 портах)
2 - работа SSP требует опускания и поднимания чипселекта на каждое слово обмена



при условии что он не знает ни момент начала очистки ни момент своего старта, требование невыполнимо

Вот именно что "enable". У меня был опыт с TI C5502, в котором при подаче RESET на CPU, проц сбрасывался, а данные в FIFO DMA оставались.


Ну хорошо если так.


У Вас неоптимально сконфигурён DMA для SSP. Там надо разрешить блоковую передачу. тогда будет ложить не по слову, а сразу будет половину SSP FIFO заполнять. при возможности.
См. DMACCxControl::SBSize и DBSize.


Кто-ж так построил систему? Почему так? А почему не постоянный или кратный некоторому целому размеру DMA?
Ну даже так - по прерыванию снятия CS тогда надо выполнять процедуру очистки FIFO и определения принятого размера.
Но лучше всё-таки сделать корректно - дополнять все транзакции до некоторого размера, кратного размеру блока DMA.


Кто Вам мешает его завести на любой пин 0го или 1го порта или EINT?


Не понял... Зачем??????
Обычно CS опускается в начале всей транзакции и поднимается в конце.

что есть оптимально? SPI работает на 8МГц клока, при тактовой проца 100, ограничение слейв режима . Времени на передачу очередного символа полно, тем более в DMA есть FIFO, что мне даст браст передача в этом случае? Только что из выходного фифо надо будет чистить ни 1 а 4 символа. И что я на вход смогу получать только сообщения кратные 4? Чет мне кажется это как раз не оптимально...


адаптация езернет системы на SPI. Сохранение протокола, ничего поделать нельзя.

Тяжелая судьба программиста, как схемотехник завел и сделал, так и будет.



А вот это прям отдельная!!!!!!! Потому что так работает slave SSP в этом проце. Он зараза по чипселекту байты из фифо в сдвиговый перекладывает и обратно. Потому если им не дергать на каждое слово, то получите только 1 слово из всего сообщения, это прям ваще все поломало!
я планировал этот Чипселект использовать как кадровая синхронизация, а вот хрен там! Опять же я не ожидал что в SSP нет прерывания на прием символа. Ровно как я что-то был не в курсе что 1 порт не является портом с прерыванием.

А вот оно так сложилось, и первая ревизия платы такая, не выбрасывать же ее теперь.
Потому у меня по проводку готовности данных происходит еще и кадровая синхронизация. И фронты я полингом отлавливаю... эх...

В общем стечение обстоятельств

интересно если 2 SSEL ноги с разных портов настроить, прокинется сигнал с одной на другую? ведь они должны соединиться внутри... может так и прерывание можно с порта на порт перенести

При 8МГц и длине слова == 1байт, у вас всего 1мкс чтобы успеть заполнить след. слово. Это довольно мало.
Лучше это время увеличить, для того и существует FIFO.
Использование burst-запросов никак не влияет на гранулярность транзакций.
Я всегда разрешаю burst независимо от кратности всей DMA-транзакции - всё прекрасно работает.

правильно не 1 микросекунда, а 100 тактов. И это время не на вспоминание следующего слова, а на выбор его из памяти для ДМА и на решение всех его конфликтов. А так как в ДМА есть еще фифо на 4 слова, то получается 400 тактов. в Таком раскладе браст просто даст борьбу ДМА раз в 400 тактов, а не барст раз в 100 тактов и все... так даже как то понадежнее выглядит.


чудно... надо будет попробовать, хотя я чет не очень понимаю как приняв меньше барста будет осуществлена транзакция... на передачу понятно, он передает по 4, и в конце сколько осталось, а на приеме то наверняка будет ждать заполнения на 4, иначе как он 4 от 1 отличит...

И кто же мешает дополнять эти кадры padding-ом до некоторого нужного размера?
Надеюсь - хоть канальный уровень протокола обмена у вас какой-то прописан, который поможет определить фактическую длину кадра?


Авторитета у вас нет
У нас если я скажу, что нужно переделать схему - переделывают, переразводят.
И в удалённых проектах, в которых участвовал - тоже.


Не надо. Это Вы что-то не так делаете. Ищите ошибку у себя. SSP (даже слэйв) в LPC не требует дёрганья CS на каждое слово.
Разрешите хотя-бы burst-запросы. Возможно что у Вас SSP выставляет burst-запрос к DMA, а раз он запрещён в DMA и не отрабатывается, то
он остаётся висеть необслуженным и SSP новых запросов не ставит, ждёт пока первый обслужится.
Вобщем - что-то Вы не так делаете.
И не надо наговаривать на проц.
SSP там хороший и прямой. Просто куча проектов уже на нём с использованием связки SSP+DMA


Так перед тем как садиться схему делать и ПО писать, сперва следует мануал на МК изучить, чтобы такого не было


А теперь ещё учтите, что в это самое время CPU выполняет программу и может читать код по этой-же самой шине. И что приоритет у CPU выше чем у DMA (к сожалению).
И что читать он может сразу пакет, и что flash имеет тактовую не 100МГц, а всего максимум 20.
У меня в реальности были проблемы с SSP+DMA даже с разрешёнными пакетными запросами на частоте 20МГц (при аппаратно-формируемом SSEL (SPI-мастер) возникали
просечки в сигнале SSEL). Из-за того что изредка не успевали данные из ОЗУ считываться. Поэтому я стараюсь не использовать на LPC17xx аппаратно-формируемый SSEL.
А у вас ещё более жёсткая ситуация.
К тому-же у Вас слэйв - это ещё хуже. Могут возникать underflow FIFO. Тут очень аккуратно надо продумывать работу CPU во время такой транзакции, чтобы он
не занимал полностью шину.


Как я понимаю - SSP автоматом определяет какой запрос ставить - burst или simple в зависимости от заполненности FIFO. Если в FIFO менее 4 слов, то,
думаю, SSP будет ждать поступления 4 слов или, по истечению таймаута, выставит simple-запрос.

И по приёму 1го слова тоже есть прерывание в SSP. И здесь Вы неправы Оно называется прерыванием таймаута.

Пробросить один сигнал периферии на 2 ноги не выходит, видать там мультиплексор...


природная лень, помноженная на здравый смысл.
Разбитие входного сообщения и отправка его по частям сулит дикий гемор с детекцией и индикацией ошибок. А выравнивать все сообщения до максимально большого - просадка по скорости обмена. Если у вас есть хорошие идея я открыт. Мне предстоит еще езернет перепихать в CAN.
езернет - есесно ТСР, то есть получение по нему проблем не вызывает, приходит целая понятная посылка.



не путаете модель LPC? Я сутки своему пытался объяснить что ему не надо дергать CS на каждый байт, а ему хоть бы хны, пока cs не дернешь второго байта не отдает... В мануале написано дергать каждый раз
Есть 3 режима SSP: SPI - требует дергать на каждый байт (мы говорим про слейв). Microwire - позволяет дергать на фрейм, но обмен идет через один по протоколу микроваер, то есть принимается каждый второй байт от мастера, а между ними считаются выходными байтами, и еще формат от тексаса, там обмен по 1 линии данных...
у филипса менялась реализация SSP, в каких то процах работает только так, в каких то можно на фрейм херачить.

Если у вас именно LPC1768 и есть SSP-slave который работает с кадровой синхронизацией я бы очень хотел это увидеть, потому что это решит некоторые мои проблемы



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



Да как бы 8 проект на этом проце, и все были с SSP, после такого некоторые свои виденья начинают казаться частями мануала. SSP-slave не было, потому вот так вышло.

А зачем это надо?
Я Вам советовал внешне сигнал пробросить дополнительно на другой порт, чтобы получить прерывание по срезу CS.
Это можно сделать и сверху, проводком допаять, чтобы не переразводить.


"Дикий гемор" - это у Вас сейчас, в текущей реализации. Потому что не сделали правильно.


У меня был LPC1758. Но думаю - это не играет роли. SSP у NXP почти не меняется со времён ARM7 ещё. И во всех CPU одинаковый.
У меня было не совсем в тему для Вас: не SSP, а SPI был. Связка: SPI+DMA+таймер. Никаким CS не дёргал.

Дело не в этом. Само это Ваше дёрганье противоречит природе SPI-интерфейса. И в принципе не должно быть такого.
Всё микросхемы работающие как SPI-слэйв все предполагают работу с опущенным CS, а по снятию CS делают сброс логики SPI (со сбросом счётчика клоков).
У Вас где-то ошибка.
Вы прочитали мой совет по поводу burst-запросов?
Ещё помнится в том проекте со слэйв SPI, CS у нас не использовался, но мы на него заводили лог. 0.
Иначе он не работал, даже если был выбран мультиплексором для GPIO, а не SPI.


Не хватает авторитета попросить схемотехника допаять доп. проводок на соседние ноги CPU???

Колхоз.... там же шлейф между 2 устройств, на разъемы, а потом сопли? Хорошо все равно не получиться а хоть как-то уже сделали. Правильнее и красивее 2 ревизию сделать. Были бы совсем вилы конечно бросили бы соплю, но пока обойдемся красивой платкой


Просто было интересно можно или нет, и опять же решает проблему некрасивых соплей, но не вышло...



Я с вами согласен%) но к сожалению проц нет. В реф мануале приведены картинки, на которых между байтами чипселект возвращается в 1 и все тут... возможности оставить его в 0 мануал не дает, а проц не воспринимает. Такое поведение только в режим microwire а в этом режиме скорость ниже в 2 раза.
Кстати ответная часть на проце другой фирмы где SPI - master по умолчанию тоже молотит чипселектом каждое слово, я даже по первости с этим сражался, пока не узнал что LPC этого и ждет...




Прочел, но дело не в этом. Я же вижу могу просто очередь фифо читать, если чип селект не дергать, данные не идут. Тут надо принять этот факт и все



Научите правильно.
посылки вида
команда - 1 байт, данные - 0 до 512 байт
ответ такой же

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

обрабатываю ошибки:
таймаут на подготовку ответ
неготовность принять посылку (2 посылка без получения ответа)
ошибка контрольной суммы в обоих направлениях

На верху это вырождается в прошла посылка - не прошла, и своей логикой действий....

как теперь это сделать правильно?




--------
читаю про burst передачу.

То есть число данных которое будет передано по появлению запроса. Получается что если пришло 3 байта, а барст стоит на 4. То либо не должно быть запроса и как следствие обмена, либо будет считано 4 байта, и последний будет - левым. больше склоняюсь к 1, что похоже на правду, потому что трудно придумать логику которая бы смогла понять надо ждать 4 символа или можно уже передавать 3, разве что по таймаут - что немного сокращает скорость обмена.

Что-то мы на разных языках похоже говорим...
Мы же вроде о том, как получить прерывание по спаду сигнала CS приходящего на Ваш МК? Этот сигнал у Вас вроде заведён на вход SSEL?
И я Вам посоветовал дополнительно завести его ещё на одну из ног GPIO 0го или 2го порта. Для этого достаточно бросить проводок с одной ноги МК
на другую этого-же самого МК. Это короткий проводок, может даже - сопля на соседнюю ногу. какие тут разъёмы???


А Вы внимательнее мануал прочитайте Посмотрите там есть вариант CPHA = 1. В этом случае как раз и не надо дёргать SSEL на каждое слово.


Я понял Вы говорите от имени МК с SPI-слэйвом, принимающего пакеты от другого МК (верха)?
Всем обменом заведует верх.
Обмен в режиме - "запрос-ответ"?

Если да, то например такой протокол:
Мастер (верх) посылает пакеты слэйву. Размер пакетов кратен 16 байт (или другое число, настраиваете DMA на такой размер, будет N блоков DMA).
При необходимости пакет дополняется в хвосте словами заполнения до кратного размера.
В заголовке пакета мастер указывает код команды и его реальную длину без учёта заполнения (при необходимости, если длину нельзя определить на основе кода команды).
Слэйв по спаду CS начинает приём пакета и контролирует его целостность по заголовку, CRC и по факту фронта CS на границе 16-байтного элемента (от неожиданных сбросов верха).
В обратном канале (MISO) слэйв всегда в заголовке пакета передаёт своё слово состояния.
Там кроме прочего будет бит готовности.
При получении пакета с командой от верха, ISR слэйва сбрасывает бит готовности и программирует DMA для след. транзакции.
В то же время он отправляет полученную команду от верха на обработку прикладному процессу.
Если, пока прикладной процесс обрабатывает данный пакет, придёт след. запрос от верха, то в обратном канале верх получит "неготов" - будет знать, что данный запрос не был выполнен.
Верх может так многократно опрашивать слэйв, посылая ему пакеты.
Как тока прикладной процесс закончит обработку запроса, он в выходной буфер помещает результат и после этого устанавливает флаг готовности.
Если ответ может быть произвольной длины и длина заранее не известна верху, то она должна быть включена в слово состояние слэйва, возвращаемое в обратном канале.

Вот как-то примерно так. Будет вполне себе кадр-ориентированный обмен хорошо ложащийся на SSP+DMA.
Только не надо забывать про опасность, что SSP в режиме слэйв на такой скорости SSP может не успеть прокачать данные из-за занятости шины CPU!
Очень аккуратно надо со слэйв-режимом LPC. Это его существенная недоработка (LPC), что нельзя выставить приоритет доступа к шине для GPDMA выше чем для ядра. (((


Нет, Вы не правы. Я же написал уже, что всегда использую burst, независимо от кратности пересылок 4байтам. Нет никаких левых байтов.
Мне кажется там всё прозрачно в описании.
Посмотрите на регистр SSPnMIS. А теперь представьте, что когда Вы работаете через DMA, то сигналы прерывания идут уже не на CPU как IRQ, а на GPDMA как DMA-запросы
(имхо - на аппаратном уровне так и сделано). Так вот - сигнал RXMIS - это burst-запрос для RX-DMA, а сигнал RTMIS - это single-запрос для RX-DMA.
Когда в RX-FIFO приходит 1ый байт (запускается счётчик таймаута), затем 2ой (без паузы) - ничего не происходит, и только когда приходит 4-ый, SSP выставляет burst-запрос к DMA,
DMA выполняет пакетную транзакцию на размер указанный в конфиге (4 байта) если может. Если-же приходит менее 4-х байт и потом - пауза, то по прошествии
времени таймаута выставляются single-запросы к DMA, которые обслуживаются одиночными операциями DMA.
В общем - работа DMA-запросов от SSP должна быть подобна работе соотв. IRQ-сигналов (см. описание на них).

соседние ноги - это тот же порт, без прерывания. Прерывания надо на другую сторону проца проводок делать, ну это так мелочи...


Вот это ценно, да действительно в CPHA = 1 можно чипселект держать в 0, там есть про это приписка, спасибо. Значит я правильно помнил что видел на осциллографе обмен без дергающегося чипселекта и какую-то запись про это, думал может другой проц, ан нет этот славно!!!! спасибо спасибо спасибо... блин на денек бы раньше, уже все переписал...


Вверх присылает данные по TCP первому контроллеру, а тот их дальше гонит по SPI как мастер уже на LPC1768. С верху приходят пакеты от 1 до 513 байт длинной, такими я их и шлю дальше обвешав контрольной суммой и длинной. Разбивка на пакеты потребует ответов о статусе каждого пакета - усложнение трафика. То есть пока не вижу большого бонуса в этом. Разьве только прерывание по окончанию пакета вместо поллинга длинны. А мусорные байты в канале так и остаются мусорными и так же гадят обмен и переполняют буфер...


ага таймаут понятно... кстати в таком раскладе 1 чтение всегда забивает полностью фифо DMA и ему надо как бы разом избавиться от всего груза, а пока шли 1 2 и 3 байты оно уже могло пытаться... Не уверен, но может это понадежнее...

В чем преимущество burst? Я понимаю если идут 32 битные данные которые надо разом записывать в память, тут я понимаю смысл burst, а если данные 1 байтные в чем бизнес?