Да на XP3.

Когда я разбирался с USB OTG, столкнулся со следующей проблемой: для нормальной работы TX FIFO необходимо занулить все неиспользуемые DIEPTXF, по примеру HAL занулил сразу 16 регистров, с запасом . Иначе FIFO глючит(и на EP0 тоже) причём на FS и HS ядрах немного по-разному. Что выглядит странно, казалось бы, как могут влиять неработающие эндпоинты.

Я победил его

Работает и под ХР3 теперь, и под 8кой. Проблема была не в FIFO и не в USB FS, а совсем в другом.

Я предполагал, что когда я IN EP устанавливаю в NAK сам, или когда она устанавливается в это состояние после передачи данных, то хост понимает, что данных просто нет. C 8кой так все и получается. А у ХР драйвер впадает в bufferoverrun и перестает принимать данные. Собственно решение посылать все время когда нет данных ZLP.

Блин, как все просто, а я за вчера почти что заново переписал половину кода, который работает с USB FS


Спасибо, буду иметь ввиду, ибо некоторые странности с FIFO все же остались.

А посмотреть примеры слабо было?

А может мне было интересно поднять это дело с нуля чисто по мануалу

А какое поведение описано в стандарте на USB?

ZLP для других случаев.

Только вот как-то на LPC не сталкивался с такой проблемой... Как-то все гладко проходило.

Genadi Zawidowski, интересно пытали ли Вы свою реализацию CDC каким-нить "стресс-тестом"?

А то я вот скармливаю VCP по 5 и 6 символов, на "другой стороне" putty все это принимает. Шлю с такой скоростью как получается. В итоге на восьмерке работает уже 15минут (средняя скорость около 450кбит/с), а на ХР затыкается довольно быстро (менее 1 минуты). Сниффер сообщает про "buffer overrun".

Я коннектился как к "Кенвуду" с помощью ARCP-590. кое-какой трафик это обеспечивает. Сутками работало.
Можете попытать мой тестовый бинарник запросами IF; - в ответ получаем самую длинную строку.

Это я так понимаю под десяткой или семеркой? Под более старшими ОС у меня по всему тоже все ок (несколько часов девайс слал данные на скорости 450кбит/с пока восьмерка не упала в BSOD по случаю IRQ NOT LESS OR EQUAL в usbser.sys ).


Это надо будет еще писать что-то для "пыток". Думал может проверяли.

Обновил сегодня Reference Manual на stm32f746. Даже кол-во эндпоинтов у USB OTG HS увеличилось на 1IN и 1OUT ? Так их реально 1CTRL + 8IN + 8OUT? Смотрю везде поисправляли, надо ж так ошибиться было.

Кстати USB раздел претерпел существенные изменения.

Загрузи с Кенвуда ARCP 590 и пусть молотит... под XP запускается. Или любой ham radio log - и пусть тестирует.
Я как-то не забываю обновлять документы, потому не удивил (и не только от ST).
Да, в HS "их реально 1CTRL + 8IN + 8OUT". В FS 1+5+5.

Я тоже, но почему-то был уверен, что он у меня новый, хорошо помню, что скачивал новый когда с DMA2D разбирался


Та не, на стресс-тест это никак не потянет.

Шаманъ, почему не тянет? Одновременно с этим в случае радио я запускал на прием панораму через HDSDR, медиаплеер в режиме воспроизведения по кольцу концерта Depeche Mode, в трансивере включал режим play usb - и сутками в наушниках была музыка, ничего не отваливалось (USB CDC при этом исправно держал соединение).
Тестовый вариант что я предоставил, в компьютер не будет передавать аудиоданных но воспроизвести в него можно.

Геннадий тут надо поделить - стресс тест для порта это одно, а для программы на МК в целом несколько иное. У Вас было скорее второе У меня тоже не сам по себе крутится CDC. Одна отрисовка панорамы/водопада 29к/с 800х480 в четырех слоях уже что-то, а еще управление DSP процессором, работа с тачем/клавиатурой/энкодерами и т.п.

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

Хочу высказать Вам отдельную благодарность, т.к. на эту мысль мена навело сравнение логов сниффера с Вашего и моего варианта CDC - обратил внимание, что у меня среднее время ответа было всегда меньше 1мс, иногда намного меньше, и как только оно сильно отклонялось обрывалась связь.

Кстати теперь надобность слать бесконечно ZLP (под ХР) пропала.

Эх жалко двух точек, которые болтаются без дела, они были бы очень кстати...

Отлично, здорово что все сдвинулось вперед.
про мой тест: там нагружалось не только CDC, но и висящей на том же USB UAC1.
хотелось узнать, чем именно отличаются логи активности CDC в моем и вашем случае (со скриншотом).
ZLP: а через хаб оно такое будет работать?

Скиншот не очень информативен. Вот кусок моего лога с кварцем:
Нажмите для просмотра прикрепленного файла
Вот от Вашего теста:
Нажмите для просмотра прикрепленного файла

Учитывая одинаковую активность на шине (в обоих случаях непрерывная посылка ZLP) усредненная длительность ответа должна дать оценку реальной длины фрейма. Так вот у Вас она скачет около 1мс, а у меня стабильно меньше (это естественно не по нескольким цифрам вывод, а после просмотра длиииинного лога - у меня выше 1мс почти нет значений). Это натолкнуло меня на мысль про частоту (или качество) кварца.


Да, работает. Более того, у Вас фактически шлются ZLP пакеты все время. У меня теперь уже не шлются .

Т.е, если нечего слать, в какое состояние переводите ендпоинт? В NAK?
upd: заменил передачу ZLP на USBD_LL_StallEP - все (и CDC и UAC) перестало работать... потом разберусь.

Она сама переведется в NAK когда FIFO опустеет. Я так сделал в самом начале, потом из-за этой проблемы убил блин три дня и переделал на посылку ZLP.

Т.е. если надо послать что-то подняли EPENA и CNAK, когда посылка будет отправлена EPENA упадет, а на входящие запросы точка будет отвечать NAK.

Подумываю еще может на передачу тоже кольцевой буфер прикрутить, хотя и без него на восьмерке около 500000кбит/с получается на мелких пакетах (чередование пакетов в 1символ и 9символов) - под наши задачи более чем достаточно.

Кстати, а Suspend и Wakeup нужно обязательно обрабатывать?

я не обрабатываю... как я понимаю, об обработке таких запросов мы сообщаем, отдавая бит что бы можем remote wakeup делать. Я не ставлю его.

Не, remote wakeup это когда девайс будит спящий хост. А я про реакцию на отсутствие активности шины - через 3мс будет early suspend, через 10мс suspend. Когда "боролся" с Win XP, заглядывал в HAL, обратил внимание, что они много ненужных прерываний включают, а потом просто флаги дергают в обработчике. Я их не обрабатываю, и все работает нормально, но вдруг есть какой нюанс? В мануале на этот счет как-то тихо.

Попробовал с CDC один "грязный хак" - указать для двух портов одну и ту же interrupt notification EP. Под ХР работает без проблем, а вот под восьмеркой увы.

Добавил аудиоустройство (пока только на вывод аудио, в смысле на ввод в компьютер). Получилась интересная штука - под ХР все работает, по восьмеркой драйвер устанавливается, система сообщает, что устройство работает нормально, но источник сигнала в восьмерке не появляется. Продолбался полдня - результат 0. Фигня какая-то... Думал самое сложное будет передачу/прием данных сделать, а вон оно как вышло.

Долго объяснять... Для проверки моей идеи поменяй product I'd например... Про то что радиоприёмник с передатчиком ставятся в запрещённой состоянии помнишь?

Это уже пробовал, не прокатило. Помогла смена типа терминала на "Микрофон" - девайс появился, но запись не работает - причем, как изначально в Zero Bandwidth восьмерка сконфигурировала интерфейс, так никаких попыток что-то включить и не предпринимает. Придется наверное и на восьмерку сниффер ставить...

На ХР все четко - включаешь запись интерфейс переключается в другую конфигурацию и все поехало, запись закончилась обратно в Zero Bandwidth.


А это как?

Это вот так:

А понятно, это я знаю, смутило слово "запрещенное состояние", везде просто написано "отключенное состояние". Но то фигня, непонятно что восьмерке не нравится. Сейчас сниффер скачаю, посмотрю. Заодно новый инструмент опробую, притом бесплатный.

Поставил Microsoft Message Analyser - очень классная штука. Но проблем по части обмена с устройством нет - все в полном порядке. Но аудио интерфес после перевода в Zero Bandwidth так и остается в нем и никаких команд более на него не отправляется. Видимо что-то не нравится восьмерке в моих дескрипторах. Где-то помнится встречал упоминание, что она хочет чтобы девайс предоставлял какие-нибудь функции управления. Добавить Feature Unit что-ли...

Олег, в моем демонстрационном бинарнике feature unit отсутствует и в приемнике и в передатчике - и ничего, работает...

Работает под чем? У меня под ХР тоже работает отлично, даже не ожидал такой засады с восьмеркой и куда копать не знаю. Блин, я в тупике...

в десятке, семерке и XP работает, надо ешё поискать у кого восьмёрка. А может это не-ZLP виновато?
Поможет ли тебе для диагностики тестовая прошивка-радиоприемник всегда выдавал тон?

Ну тогда и в восьмерке должно.

А причем здесь оно, если восьмерка даже не хочет активировать альтернативную конфигурацию AS интерфейса. Т.е. она фактически не хочет тупо включить "USB звуковуху". К тому же в изохронном обмене большого смысла в ZLP нет, разве что для начальной синхронизации.


Да я так понимаю, что можно загрузить ту, что у меня есть и посмотреть. Кстати, а как там JTAG сконфигурирован, а то мне чтобы ее вытереть пришлось BOOT0 переключать. Наверное в SWD переключен?

да, я в swd переключаю. Сейчас эта тестовая прошивка ничего не отдает...

Все нашел проблему. У меня была конфигурация 12000Гц частота дискретизации два 24битных канала, упакованных в 32битные слоты. Короче что-то в этом всем восьмерке не понравилось . Сейчас поставил 16бит 48кГц и все заработало. Возникает резонный вопрос - за что это ее так улучшили, что ХР понимал бОльше форматов?

Все, разобрался. Короче восьмерка поддерживает не все форматы, которые ХР поддерживает, это первое. Второе, она (в отличии от ХР) не обновляет конфигурацию устройств, т.е. если поменяли в дескрипторе частоту дискретизации или размер пакета, надо переустановить драйвер (собственно из-за этого все так и затянулось - я форматы сразу начал перебирать, но устройство не удалял).

Вот собственно и все. Свою проблему с не поддерживаемым форматом решил за счет перехода на 32битные сэмплы (теперь только не факт, что на ХР будет работать, завтра проверю).

Насчет переустановки (я очищаю от устройств через device manager, включив показ скрытых) - это как раз то что я предложил проверить изменив product id.

А вот еще одно на W10: если в устройстве два формата у приемника (48к*16 стерео или 96к*24 стерео) - переключается прекрасно. Если стоит например 40к*16 стерео и 80к*24 стерео - виден только первый формат. Причём, по одиночке любой их них виден...

Просто удаление устройства тоже работает (в смысле кликнуть правой кнопкой по подключенному устройству и выбрать "Удалить").

По части форматов восьмерке не понравилась упаковка 24битных отсчетов в 4байтные слоты, при этом она работает с 24битными отсчетами в 3байтных слотах и 32битными в 4х байтных, последнее это фактически то же самое, что и первое.

Решил поглядеть что там с кварцем, и обнаружил странность. Кварц генерирует как и положено ему 8000кГц (если быть точным, то 8000.5кГц), внутренний генератор (внимание!) 16380кГц, т.е. частота тактирования USB от него около 49.14МГц. При этом с ним работает, а с кварцем нет. У меня только одна мысль - джиттер, он может быть по двум причинам:
1. Дурацкий дизайн китайской платы по части генератора (они зачем-то вытянули наружу платы пины к которым подключен резонатор).
2. Плохой резонатор - может генератор работает нестабильно, "на грани" так сказать.

Интересно ли кому, что в итоге была за проблема?

А что, в конце все оказалось не в кварце? Мне - интересно.
ps: глянь на STM32F723 (STM32F723zetg6) - со встроенной HS физикой для USB HS

Поменял я кварц на 12МГц (на 8 закончились), и ... ничего - по прежнему отваливается через 10..20сек. Ну думаю может что-то не то и с этим, поставил 24.576МГц - стало лучше, но всеравно - минут 5..10 и хост на старом компе (под WinXP) отказывается принимать данные. Начал рассматривать разводку платы (речь про модуль Core7XXI от Waveshare), ну это просто жесть - вся земля порезана, переходных отверстий мало, вдобавок они маленького диаметра (0.3 что-ли), а самое главное земля к которой подключаются конденсаторы опорного генератора делает такую большую загогулину в пол платы, прежде чем доберется до процессора. Сигнал сброса тоже блуждает по плате, пока не дойдет до кнопки, причем кондер стоит со стороны кнопки (правда с этой цепью проблем нет). Далее, по питанию стоит кучка керамики 0.1мкФ и один тантал аж в 1мкФ. Резистор ООС опорного генератора зачем-то 10МОм. Ну и ноги к которым подключен кварц вытянуты на разъем платы.

Взял я ножик, паяльник и:
1. Заменил танталовый к-р 1.0мкФ на 10мкФ керамику.
2. Заменил резистор в ООС на 200кОм (как рекомендуют в датащите).
3. Добавил еще один 10мкФ керамический конденсатор по питанию в том месте где подключается питание USB у процессора.
4. Отрезал проводники от кварца на разъем платы.
Это сделало работу немного стабильнее. Но самое сильное влияние оказали перемычки - соединил ими землю около кварца с землей около процессора и с другой стороны два разрезанных полигона земли. С этими перемычками проработало 5часов (думал уже вот оно), потом правда всеравно отвалилось, но похоже это и есть проблемное место. Да, чем выше частота кварца, тем стабильнее работа, что объяснимо - коэффициент умножения ФАПЧ меньше и всякой срани тоже меньше на выходе ФАПЧ в итоге.

В общем причина в кривой разводке модуля. Кстати судя по плате следующие грабли ждут с АЦП, но там точность особая мне не нужна, метод лечения я уже продумал. Но в итоге думаю придется этот модуль переделать на свой, и наверное в 4х слоях - как всегда, хочешь сделать хорошо, сделай сам... Но для экспериментов и этот сойдет.

Да, с внутренним генератором проработало сутки без проблем, т.е. с ним таких проблем нет совсем.


О! USB2.0 это хорошо. Я так понимаю это проба, прежде чем это дело появится в high-end камнях.

Проконтролируй конденсаторы на внутреннем источнике процессора (те что 2.2 uF должны быть)

Да, и конденсаторы на кварце.

Это было первое, что я сделал - показывали по 2.5мкФ. Да и если бы здесь была проблема, то наверное сбоила бы программа на МК, а она не сбоит - просто проходят ошибки после чего хост перестает опрашивать девайс.

На кварце не мерял, но с нормальной платой соединение двух полигонов земли проводом влиять на поведение программы не должно.

Ну и так сказать happy end истории.

Решил вчера поглядеть, а что же делается на выходе PLL. Прямого выхода понятно у меня нет, но PCLK на TFT идет с одной из двух PLL. Подключил частотомер, смотрю:
1. Без перемычек частота скачет около +-1кГц (усреднение за 1сек)
2. С перемычками частота скачет в пределах +-10Гц (усреднение за 1сек)

Тут я провел эксперимент - отключил TFT, частота стоит как влитая, подключил - опять скачет. И вспомнилась мне неприметная фраза из раздела 7.1 мануала про I/O compensation cell и power supply noise reduction. Активировал эту фичу и, о чудо, PLL стала стабильно работать вне зависимости от нагрузки на I/O линии. USB тоже на старой машине теперь не отваливается (по крайней мере восемь часов сегодня и пять вчера отработало все без сбоев).

Короче мораль истории, если у Вас задействовано много I/O линий, которые переключаются с достаточно высокой частотой, включайте I/O compensation cell.

На этом похоже моя история с USB заканчивается, да модуль (два СОМ порта и дуплексная аудиокарта) получился 4.7кБ во флеше (из них примерно 0.5кБ дескрипторы) и 124байта ОЗУ. Можно было еще чуть флеша сэкономить, но я в угоду удобству программирования и красоте кода сделал обработку запросов через "карты обработчиков" и макросы, что немного раздуло код (думаю где-то на 300..500байт).

Спасибо! буду обращать внимание.