Каков источник этой формы на моей глазковой диаграмме USB?

Я разработал USB-устройство на основе STM32F105 . Это устройство USB 2.0 Full Speed ​​CDC, настроенное как виртуальный COM-порт с использованием USB-библиотеки ST . Он использует встроенный физический уровень STM32 и работает на скорости 12 Мбит/с.

Я отправляю данные пакетами по 254 байта. Время от времени (в среднем 1 из 17000 пакетов) хост-компьютер получает неверные данные. Обычно он ограничен одним байтом в пакете.

Итак, я смотрю на сигналы с помощью O-scope Tektronix TDS2025 (200 МГц).

Большинство переходов выглядят великолепно:

USB1

Но моя низкотехнологичная глазковая диаграмма показывает нечто неожиданное:

Глаз

Мне удалось поймать один из плохих сигналов, который выглядит так:

USB2

Что может быть причиной этого? Я не уверен, с чего начать поиск.

Когда я впервые подключаю устройство, перечисление проходит успешно, и глазковая диаграмма выглядит чистой. Но как только я открываю COM-порт (используя PuTTY, Hercules или мое собственное программное обеспечение Java), появляются сбои. Я использую Lenovo Thinkpad с Windows 7.

Вот фото макета:

печатная плата

Микросхема TVS — это NXP PRTR5V0U2F , а детектор зарядного устройства — TI BQ24392 .

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

Я прощупываю от контактных площадок USB-разъема до точки заземления, которую я пометил на картинке. Зонд имел короткую заземляющую пружину, а не длинный зажим типа «крокодил».

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

2.2R в качестве последовательного резистора для ваших линий передачи данных мне кажется довольно низким. Можете ли вы подтвердить, что это 2.2R, а не 22R, как я ожидал? У вас есть эталонный дизайн, откуда вы это взяли? Кроме того, можете ли вы подтвердить, что вы хотя бы пытались проложить сигнальные линии usb такой же длины и примерно 50 Ом?
Маловероятно, что ТВС или детектор заряда так мешают сигналу. Я понятия не имею, почему STM32 демонстрирует такое поведение.
Это похоже на отражение, но оно должно быть на довольно длинном кабеле. Может быть, какие-то разногласия? Я думаю, что моим первым действием по отладке было бы отпаять детектор зарядного устройства и соединить его парой проводов.
Я бы поискал проблему в другом месте. Этот сигнал выглядит как переход от движения (1 или 0) к высокому Z.
@TomL., да, они 2.2R. Это получено с рабочей платы разработки, предоставленной производителем радиочастотного приемопередатчика с использованием того же микроконтроллера, но я никогда не проверял сигнализацию платы разработки... Похоже, я должен использовать 22R :) Кроме того, да, трассы были смоделированы для 90- Ом дифференциал, и были сохранены близко к той же длины. Каждый из них примерно один дюйм в длину. Они меняются с верхнего слоя на нижний прямо на детекторе зарядного устройства, обратно — прямо на микроконтроллере.
Отражение (где бы оно ни было) переходит в более низкий импеданс (отражение не в фазе). Я бы предположил, что два разных сигнала — это два разных направления передачи сигналов.
@GregoryKornblum У меня была такая же мысль. К USB-линиям больше ничего не подключено. Я мог бы попробовать использовать более новые библиотеки USB от ST; может те, что я использую, глючат?
@Фотон. Спасибо. Сначала я проверю теорию отражения, потому что мне проще заменить резисторы, чем припаять к этим крошечным контактным площадкам :)
Эти резисторы, вероятно, являются последовательным окончанием, требуемым спецификацией USB. Согласно спецификации, они должны быть около 16R-33R (2,2 определенно слишком мало), чтобы учесть разное сопротивление USB-кабеля. Это может вызвать проблемы, но они, вероятно, не будут отображаться так, как вы видите на самом деле (они должны быть более последовательными). Я бы все же подумал о том, чтобы их поменять.
Попробуйте сэмплировать в середине сигнала — глазковая диаграмма выглядит достаточно хорошо для правильного декодирования.
Кто-нибудь может объяснить происхождение и значение «глазковой диаграммы»?
Спасибо за отличную ссылку, @TomL. Я никогда не сталкивался с этим раньше.

Ответы (3)

Не похоже, что это аппаратная проблема. Ступенчатая форма волны выглядит либо как отражение, либо как переход, когда хост и устройство меняются ролями отправителя и получателя. В любом случае сигнал выглядит достаточно хорошо, чтобы его можно было правильно декодировать.

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

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

Спасибо, Олин. Оказалось, что это программная ошибка. USB-библиотека ST заполняет исходящую очередь по одному байту за раз ( Buffer[index] = data; index++;). Когда я создал свою собственную функцию, я сделал это следующим образом: Buffer[index++] = data;по-видимому, процесс USB (очень редко) происходил после увеличения индекса, но до того, как данные были записаны.

Это абсолютно идеальный сигнал FS. По-видимому, OP проверяет сигналы на конце кабеля устройства. Сигналы FS не терминированы по стандарту USB. Все входящие сигналы (управляемые хостом) в порядке, поскольку они измеряются в точке назначения. Однако, когда устройство возвращает случайный пакет подтверждения (короткий ACK или NAK или что-то еще), драйвер подключается к линии передачи. Сигнал половинной амплитуды (шудер) развивается до тех пор, пока не вернется отражение от принимающего конца. Это абсолютно нормальное поведение сигналов на нетерминированной линии передачи. Как я вижу, задержка туда и обратно составляет около 20 нс или 10 нс в одну сторону. Это говорит о том, что используемый кабель имеет длину около 2 м или стандартный кабель длиной 6 футов. Если бы OP прощупал шину на стороне хоста, он увидел бы противоположную картину. Только мой 2с.

Отлично, Али, спасибо! Это то, что я искал. Извините, что я уже принял другой ответ...

Я отправляю данные пакетами по 254 байта. Время от времени (в среднем 1 из 17000 пакетов) хост-компьютер получает неверные данные. Обычно он ограничен одним байтом в пакете.

Используете ли вы FIFO? Если это так, проверьте свой исходный код: есть плохие примеры FIFO, которые фактически позволяют читать «плохой» байт.

«Плохая форма сигнала» все еще находится в пределах спецификации. Вероятно, вы видите отражение, когда ПК отправляет данные. Это будет лучше при использовании концентратора или портов на задней панели настольного ПК и хуже при использовании портов на передней панели, которые подключены более длинными кабелями внутри ПК.

Каков источник этой формы на моей глазковой диаграмме USB?
СпросиСетьПолитика конфиденциальности1y, 0v