Jump to content

    

loltrol

Участник
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

0 Обычный
  1. MSP430F5529 usb не жужжит через hub

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

    Цитата(controller_m30 @ Jan 23 2015, 13:57) А какая настройка стандарта USB в BIOS тех компьютеров? Я встречал выбор из 1.0, 1.1 и 2.0. В современных наверное и 3.0 добавилась. Может Хаб передаёт данные устройства в компьютер, но тот, находясь в FS или LS режиме (принудительно заданном в BIOS) "не дружит" с быстрым Хабом? Случилось чудо)) И как всякое чудо оно не поддается объяснению, а требует только веры в него На том компе, где через хаб не работает, в BIOS выключил режим USB 2.0 и девайс определился. Т.е. скорее всего хаб работал на HS и почему-то трансляция скоростей не проходила, загнав хост в режим USB 1.1, хаб стал работать в режиме репитера - и тут всем полегчало. Собственно, ничего яснее не стало )) Почему с одними хостами хабы могут работать нормально в режиме транслятора, а с другими нет. Что-то такого поведения с обычными мышами и клавами не наблюдал. Есть у меня устойство с тем же кодом, тот же HID но на ARM-7 (LPC2142, спецом поменял на нем код, сделав размер буфера контрольной точки 8 байт как на MSP) сравнивал поведение - разница одна: MSP почему-то после первого запроса GET_DESCRIPTOR_DEVICE и своих двух посылок по 8 байт делает паузу секунд на 5, после чего процесс обмена продолжается, на LPC все проходит без пауз. Вполне возможно, что для хаба в режиме трансляции это критично, точнее для хоста (для некоторых, зав от релиза, разные таймауты). Дело осталось за малым: понять в чем причина - устройство коммерческое и пользователям не на объясняешь, что им надо уронить некий "хост" в некий режим "FS" ))) Сделал скриншот обмена выведенного в терминал
  3. MSP430F5529 usb не жужжит через hub

    Цитата(controller_m30 @ Jan 22 2015, 13:02) Вот один вариант. Контроллер работает как FullSpeed или LowSpeed устройство - для которых буфера 8 байт достаточно, а Хаб умеет работать только как HighSpeed - и ему подавай 64-байтные пакеты. В общем пакеты не той длины. Или для Хаба не установлены драйвера (если это возможно - не знаю), или не та прошивка\настройка для поддержки Low и Full-Speed устройств. Другой вариант - скорость. Если Хаб High-Speed, то минимальная скорость транзакций должна быть 25 мегабит, а у Full-Speed максимум 12 мегабит (Low-Speed ещё меньше). Возможно Хаб не может обнаружить данных на той скорости на которой работает контроллер. Проверьте на другом Хабе своё устройство. Беда в том, что проверяю с одним и тем же хабом - на некоторых компах работает, на некоторых - нет. Жесткой зависимости от операционки и древности компа нет, есть оч древние компы на ХР с которыми все ОК. История тащится уже года три, точно помню что с хабом в моем мониторе раньше не работало, не так давно сменил комп и с удивлением обнаружил, что связь с устройством через мониторный хаб появилась. Т.е. проблема в хосте, НО убивает именно последовательность: хост - устройство: ОК! хост-хаб-устройство: фак! но запросы от хоста устройство видит, добросовестно шлет ответы Чувство такое, что все упирается в размер буфера EP0 - но почему.....
  4. MSP430F5529 usb не жужжит через hub

    Цитата(mcheb @ Jan 22 2015, 02:51) Есть такая штука ZLP . Внимательно читать спецификацию USB ! А что-нибудь конструктивнее общеукрепляющих пожеланий нет?
  5. 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) Точно не проблемы со связью - осциллограмы вполне нормальные да и хаб один и тот же - с одним компом работает, с другим - нет. На ноутах ситуёвина хуже - там и без внешнего хаба от ноута к ноуту то работает , то нет.
  6. MSP430F5529 как HID устройство норм работает напрямую с компом, при подключении ч-з внешний HUB (всегда) и на ноутбуках(не на всех) не определяется. Ситуация ставит в ступор: мониторю запросы от хоста и вижу что он в принципе или не понимает ответов или не получает их - тупо шлет непрерывно GET_DESCRIPTOR_DEVICE и все. Аналогичный код жжужит на LPC2142 без проблем - разница одна: размер хв буффера EP0 у MSP - 8 байт, у LPC - 64. Может кто встречался с подобным или хотя бы отпишите что этот проц работает ч-з внешние хабы.
  7. Цитата(Aner @ Jan 20 2015, 14:34) C PP давно ушел на Lwip, чего и вам советую. РР ну очень сырая была тогда, незнаю как сейчас. 100500 и была и есть сырая. Иногда стоит мегаусилий заставить их код работать, что USB-bulk, что WEB-сервер - оч крупный рашпиль применяется )) особенно при полном отсутствии исходников. Выбор PP щел от компилятора, честно Lwip просто не попался под руку, спс за наводку.
  8. Опишу ситуацию, чтобы другие не попадались: RMII интерфейс связи пришлось использовать по скудости пинов, но внимательно изучить разницу было недосуг - в итоге из виду ушло что тактирование приема данных от физдрайвера процом осущетсвляется самим процом (от сигнала пина MCO на пин ETH_RMII_REF_CLK) и естественно по оч короткому пути (15 мм). Тот же клок идет до физдравера по дорожке примерно 80-90 мм и на двухлучевом осциле замеряется задержка в 5-6 нс. Ну а дальше простая арифметика - задержка данных на пинах физдрайвера до 14 нс (по даташиту), плюс ход данных до проца до 5-6 нс (по замеру) - и имеем что может быть ситуация считывания процом данных которых еще нет (считывание данных идет вторым тактом - т.е. чз 20 нс а валидные данные могут появится чз 25 нс). Что, в пинципе, мы и имеем: плавающий эффект - то работает 2-3 дня, то дохнет чз 10-15 минут после включения - не отлипает, видимо, по особенностям софта (PP IAR). Наблюдая осцилом зависший Ethernet, видно что данные от физдрайвера идут абсолютно адекватные, а проц просто их игнорит. А если еще и плата плохо помыта и флюс под процом - эффект падежа гаратирован ((
  9. Спасибо за помощь! Пока обнаружили другую проблему: из-за избыточной длины проводника данные с физ. драйвера приходят на проц с запаздывающим (на пол-такта) тактированием. Возможно, причина в этом. Будем переразводить плату, по результатам постараюсь отписать.
  10. Разницу 10 и 100 не проверяли, в эрратах ничего нет. Терминальные резисторы - на STM3210C-EVAL, которую привёл A. Fig Lee, между процом и физдрайвером стоят согласующие резисторы 33 Ом. У нас таких нет. Aner, а вы используете PowerPac'овский модуль Ethernet? Мы явно не используем DMA; только указали выходы проца, всё остальное делает PowerPac TCPIP. И ещё: мы используем RMII (не хватило ножек). У вас также или MII?
  11. PLL3 тактируется кварцем (25МГц) и дает на выходе 50 МГц. PLL2 тактируется кварцем (25 МГц), на выходе - 40 МГц. PLL1 тактируется от PLL2/5 = 8 МГц, на выходе 72 МГц. DP83848 тактируем PLL3. Правда, точность вряд ли лучше 50 ppm, однако грели феном схему что бы вызвать сбой - сбоя не случалось. Нужно ли ставить терминальные резисторы на сигнальные линии от проца к драйверу? Грешим на отражения, а от физдрайвера к трансу они стоят (49.9 Ом).
  12. Есть устройство на STM32F107 и физ. драйвере DP83848. Работает на PowerPac RTOS (full, не evaluation) из-под IAR 6.2. Периодически отмирает Ethernet. Вначале падал чётко через 15 минут, грешили на какие-либо программные глюки. Однако впоследствии стал умирать совершенно случайно и внезапно. Может проработать 2 минуты, а может и 2 часа. Иногда встречаются периоды просветления и работает часов по 12. Одновременно вертится несколько задач, но пробовали запускать лишь одну. Когда Ethernet работал по 15 минут пробовали останавливать программу дебаггером - после продолжения всё равно работал те же 15 минут и умирал. Ethernet умирает даже если прибор не подключён к ЛВС (т.е. запускаем, ждём минут 20-30 и подключаем сеть - ноль эмоций). Какие могут быть подводные камни? Рука уже тянется к топору :-(