Приветствую участников!

Есть ус-во которое должно передавать в ПК данные. Для этих целей в нём реализована связка: USB - FT232R - ADum1402(развязка) - МК.
Скорость 921600. Управление потоком не используется. Протокол обмена: ПК выдаёт запрос (2 байта) в ответ получает 256 байт данных.

Проблемы: периодически ПК недополучает данные, иногда десятки байт.
В этой связи экспериментировали с размером ответной посылки (уменьшали до 62 байт), понижали скорость передачи до 115200, но сбои всё равно происходят...

Кому-нибудь приходилось сталкиваться с чем-нибудь подобным?

Нет. Работаю на 115200 без управления потоком, проблем нет.
Хотел было сказать, что на 921к надо работать с хэндшейкингом, но коли у вас и на 115 проблемы... Может бодрейт МК не совсем 921 или 115 из-за неправильной конфигурации или ухода генератора. Осциллом смотрели на импульсы?

Смотрел, но с точностью до процентов период следования импульсов не замерял... проверю.
Кстати мы используем драйвер VCP, а Вы?

И vcp и D2xxx (через обертку для .NET) использую.

Хотя знаете... для кривого бодрейта все же характерно искажение, а не потеря данных. Хм... я б все же грешил на хэндшэйкинг, но если и на 115 не работает... Схема включение микросхемы стандартная, как в даташите? А до FT232 гарантировано данные долетают из МК? Может ошибка в софте МК/ПК? Просто ни разу не замечал потери в FT232, никогда не использую хэндшейкинг.

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

После того как проявилась проблема, к поиску ошибок подключилось ещё два специалиста помимо меня, один из них с нуля написал софт нижнего и верхнего уровней и проверка ведётся на макетной плате, т.е. коды инициализации UART'a микроконтроллера для 921600 и на 115200 написаны разными людьми и ошибка крайне маловероятна, также маловероятны какие-либо аппаратные неисправности т.к. эффект присутствует и в устройстве и на макетке. Схема включения FT232RL стандартная, я полагаю, что если бы проблемы были-бы, скажем, из-за питания/помех/итп то это должно было бы приводить к зависаниям а не к потере десятков байт данных...

И ещё один момент: в другом устройстве на 115200 всё работает, но длина пакета там не превышает 10 байт... По какому протоколу Вы обмениваетесь и какой длины посылки посылаете в РС?

Начните с простого: отключите ADuM, замкните у FTDI ноги Rx и Tx, пошлите в терминалке текстовый файл, предварительно настроив на запись лога в файл. Потом сравните полученный файл с исходным. Должны совпадать. Потом подключите ADuM, отключите МК. Повторите проверку. Нет там никакой зависимости от длины пакета. Посылал 65К и на 115200 и 460800 - прекрасно все проходит. На 921600 у меня проц не успевает разгребать. Нет там аппаратных ошибок внутри FTDI, если вы на это намекаете. Чем ADuM питаете? Ощущение, что проблемы где-то в питании - как будто питание паразитное от информационных входов. Начинаетеся обмен - питание пропадает.

Господа, авторы ПО верхнего уровня нашли причину...

Виндовз тормозила с выдачей данных, это воспринимали как потерю, хотя потери на самом деле не было.

Благодарю всех за советы.)

Хотя и разобрались, но для истории.
Была проблема с этим чипом, хотя и исключительно по моей вине, но может натолкнет кого на мысли, если будут похожие симптомы. Дело в том, что я по глупости поставил на противоположной от FTDI стороне платы Bluetooth модем и когда он излучал, данные в FTDI терялись и искажались. Глупость конечно, очевидная, но может я не один такой буду