loltrol

Проблема порешалась, но, как грится, осадочек остался. Хост после первых 8 байт дискриптора желал прервать передачу и сообщал об этом пакетом OUT, который не принимался устройством: вот тут вопрос кнешно к TI, почему они в регистре USBOEPCNFG_0 после каждой передачи данных устройством по пакетам IN выставляют бит NAK, который и не дает хосту выслать свой ASK устройству (( Теперь, по каждому прерыванию по пакетам IN тру бит NAK для пакетов OUT и инициализация проходит мгновенно, и, как следствие, стало работать и с хабами которые работают на HS. Мдя...

Случилось чудо)) И как всякое чудо оно не поддается объяснению, а требует только веры в него На том компе, где через хаб не работает, в BIOS выключил режим USB 2.0 и девайс определился. Т.е. скорее всего хаб работал на HS и почему-то трансляция скоростей не проходила, загнав хост в режим USB 1.1, хаб стал работать в режиме репитера - и тут всем полегчало. Собственно, ничего яснее не стало )) Почему с одними хостами хабы могут работать нормально в режиме транслятора, а с другими нет. Что-то такого поведения с обычными мышами и клавами не наблюдал. Есть у меня устойство с тем же кодом, тот же HID но на ARM-7 (LPC2142, спецом поменял на нем код, сделав размер буфера контрольной точки 8 байт как на MSP) сравнивал поведение - разница одна: MSP почему-то после первого запроса GET_DESCRIPTOR_DEVICE и своих двух посылок по 8 байт делает паузу секунд на 5, после чего процесс обмена продолжается, на LPC все проходит без пауз. Вполне возможно, что для хаба в режиме трансляции это критично, точнее для хоста (для некоторых, зав от релиза, разные таймауты). Дело осталось за малым: понять в чем причина - устройство коммерческое и пользователям не на объясняешь, что им надо уронить некий "хост" в некий режим "FS" ))) Сделал скриншот обмена выведенного в терминал

Беда в том, что проверяю с одним и тем же хабом - на некоторых компах работает, на некоторых - нет. Жесткой зависимости от операционки и древности компа нет, есть оч древние компы на ХР с которыми все ОК. История тащится уже года три, точно помню что с хабом в моем мониторе раньше не работало, не так давно сменил комп и с удивлением обнаружил, что связь с устройством через мониторный хаб появилась. Т.е. проблема в хосте, НО убивает именно последовательность: хост - устройство: ОК! хост-хаб-устройство: фак! но запросы от хоста устройство видит, добросовестно шлет ответы Чувство такое, что все упирается в размер буфера EP0 - но почему.....

А что-нибудь конструктивнее общеукрепляющих пожеланий нет?

MSP430F5529 как HID устройство норм работает напрямую с компом, а при подключении ч-з внешний HUB не определяется. При мониторе запросов от хоста и вижу что он в принципе или не понимает ответов или не получает их - тупо шлет непрерывно GET_DESCRIPTOR_DEVICE и все. Аналогичный код жжужит на LPC2142 без проблем - разница одна: размер хв буффера EP0 у MSP - 8 байт, у LPC - 64. От хаба не зависит - при подключении к некоторым компам через хаб устройство работает, зависимости от операционки нет - пробовал на ХР и на 7 - никакой системы. Устройство питание от USB не использует, запросы точно понимает - выводил весь обмен по UART для мониторинга в реальном времени - картина всегда одна: 1) от хоста: запрос GET_DESCRIPTOR_DEVICE 2) от устрйства первые 8 байт DEVICE дескрипотра 3) от устрйства вторые 8 байт DEVICE дескрипотра 4) хост производит сброс шины и начинает с п. 1) Точно не проблемы со связью - осциллограмы вполне нормальные да и хаб один и тот же - с одним компом работает, с другим - нет. На ноутах ситуёвина хуже - там и без внешнего хаба от ноута к ноуту то работает , то нет.

MSP430F5529 как HID устройство норм работает напрямую с компом, при подключении ч-з внешний HUB (всегда) и на ноутбуках(не на всех) не определяется. Ситуация ставит в ступор: мониторю запросы от хоста и вижу что он в принципе или не понимает ответов или не получает их - тупо шлет непрерывно GET_DESCRIPTOR_DEVICE и все. Аналогичный код жжужит на LPC2142 без проблем - разница одна: размер хв буффера EP0 у MSP - 8 байт, у LPC - 64. Может кто встречался с подобным или хотя бы отпишите что этот проц работает ч-з внешние хабы.

100500 и была и есть сырая. Иногда стоит мегаусилий заставить их код работать, что USB-bulk, что WEB-сервер - оч крупный рашпиль применяется )) особенно при полном отсутствии исходников. Выбор PP щел от компилятора, честно Lwip просто не попался под руку, спс за наводку.

Опишу ситуацию, чтобы другие не попадались: RMII интерфейс связи пришлось использовать по скудости пинов, но внимательно изучить разницу было недосуг - в итоге из виду ушло что тактирование приема данных от физдрайвера процом осущетсвляется самим процом (от сигнала пина MCO на пин ETH_RMII_REF_CLK) и естественно по оч короткому пути (15 мм). Тот же клок идет до физдравера по дорожке примерно 80-90 мм и на двухлучевом осциле замеряется задержка в 5-6 нс. Ну а дальше простая арифметика - задержка данных на пинах физдрайвера до 14 нс (по даташиту), плюс ход данных до проца до 5-6 нс (по замеру) - и имеем что может быть ситуация считывания процом данных которых еще нет (считывание данных идет вторым тактом - т.е. чз 20 нс а валидные данные могут появится чз 25 нс). Что, в пинципе, мы и имеем: плавающий эффект - то работает 2-3 дня, то дохнет чз 10-15 минут после включения - не отлипает, видимо, по особенностям софта (PP IAR). Наблюдая осцилом зависший Ethernet, видно что данные от физдрайвера идут абсолютно адекватные, а проц просто их игнорит. А если еще и плата плохо помыта и флюс под процом - эффект падежа гаратирован ((

Спасибо за помощь! Пока обнаружили другую проблему: из-за избыточной длины проводника данные с физ. драйвера приходят на проц с запаздывающим (на пол-такта) тактированием. Возможно, причина в этом. Будем переразводить плату, по результатам постараюсь отписать.

Разницу 10 и 100 не проверяли, в эрратах ничего нет. Терминальные резисторы - на STM3210C-EVAL, которую привёл A. Fig Lee, между процом и физдрайвером стоят согласующие резисторы 33 Ом. У нас таких нет. Aner, а вы используете PowerPac'овский модуль Ethernet? Мы явно не используем DMA; только указали выходы проца, всё остальное делает PowerPac TCPIP. И ещё: мы используем RMII (не хватило ножек). У вас также или MII?

PLL3 тактируется кварцем (25МГц) и дает на выходе 50 МГц. PLL2 тактируется кварцем (25 МГц), на выходе - 40 МГц. PLL1 тактируется от PLL2/5 = 8 МГц, на выходе 72 МГц. DP83848 тактируем PLL3. Правда, точность вряд ли лучше 50 ppm, однако грели феном схему что бы вызвать сбой - сбоя не случалось. Нужно ли ставить терминальные резисторы на сигнальные линии от проца к драйверу? Грешим на отражения, а от физдрайвера к трансу они стоят (49.9 Ом).

Есть устройство на STM32F107 и физ. драйвере DP83848. Работает на PowerPac RTOS (full, не evaluation) из-под IAR 6.2. Периодически отмирает Ethernet. Вначале падал чётко через 15 минут, грешили на какие-либо программные глюки. Однако впоследствии стал умирать совершенно случайно и внезапно. Может проработать 2 минуты, а может и 2 часа. Иногда встречаются периоды просветления и работает часов по 12. Одновременно вертится несколько задач, но пробовали запускать лишь одну. Когда Ethernet работал по 15 минут пробовали останавливать программу дебаггером - после продолжения всё равно работал те же 15 минут и умирал. Ethernet умирает даже если прибор не подключён к ЛВС (т.е. запускаем, ждём минут 20-30 и подключаем сеть - ноль эмоций). Какие могут быть подводные камни? Рука уже тянется к топору :-(