Работаю с CY7C68013A в режиме синхронного slave fifo, EP6 настроена как IN в AUTOIN mode c EP6AUTOINLEN = 0x200, quad buffered. Мастер пишет в EP6 данные и когда ему приходит команда - заканчивает запись дергая PKTEND вместе с последним SLWR. Размеры таких пакетов могут быть от 4х байт до нескольких килобайт. Проблема в том, что если размер отсылаемых данных случайным образом совпадет с 0x200 - то пакет просто "исчезает". В принципе проблема решается если флаг ZEROLEN поставить в 1 и PKTEND дергать через такт после последнего SLWR, но так бы делать не хотелось... Если кто знает - подскажите плиз как лучше решить данную проблему. Считать байты просьба не предлагать-)) Спасибо!

Я дергал PKTEND через много клоков после последнего SLWR. Стоял счетчик и если не приходили данные в течении 2^16 слоков то срабатывал PKTEND.
Флаг ZEROLEN был в нуле.
Попробуйте так. Или вам как то мешает задержанный PKTEND ?

Да просто не хочется "лишних" тактов.

Вообще мне немного непонятно в моем случае поведение EP6 в AUTOIN режиме. Если не использовать PKTEND, то данные отсылаются драйверу только после заполнения всего буфера 2048 байт. По идее же если EP6AUTOINLEN = 0x200, то данные должны отсылаться драйверу как только в буфере 512 байт без PKTEND? А этого не происходит. Если поставить например EP6AUTOINLEN = 0x100, то данные начинают отсылаться драйверу как только в буфере 0x100 байт. Сам обмен in/out происходит без ошибок.

Я посмотрел в коде - это то как у меня был сконфигурован EP6


По поводу ZEROLENIN я ошибся он равен 1.
EP6AUTOINLEN похоже никто не игрался...
Пропажа даты замемечена не была... Попробуйте сделать так...

А зачем экономите такты ? Есть на то обьективная причина ?

Как раз задерживаю PKTEND на 1 такт после последнего SLWR при передаче блока, ZEROINLEN=1 (точнее EP6CFG = 0xE2; EP6FIFOCFG = 0x09+0x04;), дергаю PKTEND не зависимо от того, чему кратен был размер блока. Никаких проблем не наблюдаю, да и не вижу причин, почему бы не "дергать" его именно так, как собственно советует сам цайпрес (второй совет цайпреса был именно считать байты и отключить AUTOIN, дабы AUTOIN не конфликтовал с PKTEND-ом).

Сенкс, это все уже пробовал-) Дело даже не в "экономии", а в том, что все уже четко и стабильно работало, а тут всплыл этот момент с пакетом в 512 байт, поэтому хотелось бы перешить еепром а не переделывать прошивку CPLD.




Спасибо за ответ. Да я добавил лишний такт перед PKTEND и сделал ZEROLENIN = 1, 512байтовый пакет отсылается, но блин появился какой-то "плавающий глюк" - иногда в фифо пишется лишнее слово, буду разбираться в чем дело... А почему если вы не стали использовать AUTOIN = 0? Были какие-то проблемы (я просто не успел попробовать еще)?

Могу сказать, что этот (или похожий) глюк наблюдаю и я, и поймать его пока не поймал, как и закономерности не нашел. Решил этот вопрос программно в драйвере, так как во всех случаях слово проскакивает тогда, когда вообще передачи IN быть не должно, но была OUT, и PKTEND-а тоже не было. А во время IN-передачи гарантировано ничего не проскакивает, как и после нее до следующей OUT. Т.е. принимаю все данные, и беру те, что с конца, в том объеме, что надо. Вначале грешил на EMI, разводку, питач, и т.п., потом эта версия была отброшена экспериментально. От цайпреса на эту тему тоже ноль информации.


Раньше в ПЛИСину не лезла считалка слов, плюс к тому, что надо было еще и организовать регистр длины пакета в ПЛИС, ибо в фулл спиде и в хае оно разное. Теперь все лезет, но уже написано и работает, тут принцип "его не трожь, оно и не воняет". А вот в очередной модернизации я убираю CY, заменяя его на USB-IP-core в ПЛИС, там, разумеется, по любому счетчик слов будет, и никакого PKTEND.

Просто огромнейшее спасибо за эту информацию-) А то из-за таких вещей мозг просто разрушается иногда-))) Наверное просто сделаю проверку на размер отсылаемого пакета и все, раз такая фигня.



Тоже надеюсь, что в будующем не будет внешнего HS USB контроллера-)