вот такая убийственная проблема:
Соединяем плату с AT91SAM7S256 к компьютеру через USB - компьютер перезагружается, но не каждый раз, и начинает перегружаться после первых 20-40 соединений.
Сожжена материнская плата . На другом компьютере тоже стал перегружаться, так что эксперементировать в том же духе не хочется.
Еще один момент - если при перезагрузке не отсоединить USB, то перегружается по кругу.
Питание платы выключено.
Соединяли через USB-хаб - не помогало (а точнее сперва соединялось, потом вобще перестало).

Ни у кого знакомых предположений о причине сего нет. Единственное - может с драйвером что? драйвер установлен с SAM-BA 1.7, может есть другие его варианты, не знаю ...

Кто-нибудь сталкивался с такой проблемой?
Нашли причину? А может даже её решение? - поделитесь, пожжжалуйста

Хм... забавно!

А питалово с ЮСБ берете? Не пробовали питалово подавать с внешнего источника? Реакция такая же?

Я точно не знаю, только предположение.

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

Если это не по питанию, значит надо тараканов искать в программном обеспечении. Но я что-то не очень представляю багу, которая приводит к перезагрузке компа. БСОД -- это я понимаю, но аппаратная перезагрузка (((((((( тем более софт не уникальный, распространен широко. Т.е. у каждого такое может быть.

скорее всего каличный usb2serial драйвер - отсутствуют какие-то проверки, принял чего-то не то и застрелился, небось windowz ? подключите к linux машине там можно включить отладку в usbcore и довести arm часть до ума, а потом уже втыкать в винду.

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

Так-что firmware надо проверить очень основательно

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

Что касается перезагрузки, то:
1. Передается в комп больше, чем заявлено (посмотрите размеры дескрипторов)
2. Передается меньше, чем заявлено
3. Посередь энумерации девайс останавливается молча - винде плохо

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

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

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

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

Согласен, дело может быть и не в плате с SAM7S. Могу только повториться про южный мост.
Сам в своё время напоролся на эту проблему: в первой матери Asus сгорели только USB-порты, а во второй - весь южный мост. В общем, любовь к Asus стоила конторе закупкой ещё 6ти матерей (не я один оказался такой счастливый).
Покупайте продукцию производства intel!

Коллеги!

Не надо искать черную кошку в темной комнате, особенно когда ее там нет. Ищите ошибки в собственном проекте.

Еще раз повторю. Если не происходит нормально процесс подключения USB устройства к компьютеру (enumeration), то все падает в тар-тарары. Кстати меня это наводило на грустные мысли по поводу всяких там идей про ring0 - ring3 защиты в OC и прочие прибамбасы. Летит все сразу к чертям.

В часности, когда я задал размер конечной точки больше максимального, при запуске программы Windows перезагружался (даже не перезагружался, а происходил RESET) и не загружался пока не вытаскивал USB-устройство.

На большом количестве чипсетов , с большим количеством драйверов проверено :
такое происходит как ни странно изза срыва тактовой частоты USB устройства(касается класса CDC в основном). пример пальцем кварц на FTDI достаточно коснуться - комп ресетиться.
Поспробуйте покопать в этом направлении.

Чисто для интереса - а устройство часом не бутовое?

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


Я, честно говоря, не знаю что такое бутовое устройство.....

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

В общем, проверяйте тщательно энумерацию, особенно - размеры.

Не нужно мешать всё в одну кучу. ОС (в частности Windows) устроена так, чтобы приложение только в User-mode (ring3) не могло вывести ОС из строя. А при подключении USB устройства первыми активизируются драйвера Kernel-mode (ring0), в частности драйвер шины, а в Kernel-mode разрешено всё по определению, поэтому любое неверное телодвижение сносит "крышу" однозначно. На то он и Kernel ...

Ничего не понял Сейчас пойду листать Солдатова...

А что, Винде так трудно обработать ошибочную ситуацию с подключением кривого устройства? Что, разве так сложно отключить драйвер? А как же всеми нами любимый BSOD? И почему так сразу без предупреждения сваливаться в жесткую перезагрузку? По моему, это явный баг от MS. Напильниками там ребята разучились работать, вот и говорят - "фича такая!". Да не фича это! А руки такие кривые!

На уровне Kernel (RING0) никакой "Винды" уже практически нет - и некому "схватить за руку" зарвавшееся приложение. Привожу простой пример. Драйвер ожидает, что устройство должно прислать ему 13 байт - он выделяет буферную переменную на 13 байт. Где ? Правильно, на стеке, переменная-то локальная. А устройство, собака, прислало не 13 байт, а 14. Куда девался лишний байт ? Записался куда-то туда же на стек. Что ещё хранится на стеке ? Адрес возврата из процедуры, верно ? Значит, лишний байт запросто мог снести адрес возврата из процедуры. Куда улетит процессор после возврата из процедуры - очень вероятно, что на перезагрузку. Иногда куда-то туда, где его ещё могут тормознуть силы операционной системы, сгенерить исключение, выдать знаменитый BSOD ... Но увы, не всегда.

В User-mode такой прыжок просто приведёт к исключению (Access Violation) - и приложение будет с позором выдворено из системы. А на уровне ядра на исключения не всегда приходится рассчитывать, особенно в процедурах обработки прерываний, где код драйвера выполняется на высоких приоритетах ...

Мне кажется, здесь еще обойдён такой вопрос:
У нас, когда сухо, суёшь флэшку в комп - и комп перегружается. Статикой стукает.
Так может там просто надо соединить земли устройства и компа.
Допустим, комп без евророзетки, на корпусе сидит половина сетевого напряжения, устройство запитано вообще ХЗ от какого БП. Какое напряжение между их землями? Тут и мамка сгореть может...

Ага, бывает и такое.

На прошлой неделе мне нужно было получить на свою флешку файл с флешки партнера. Проблем нет!

Офис, конец рабочего дня, почти все компы выключены. Подошли к человеку, у которого комп включен. На компе было несколько свободных USB-входов -- можно осуществить "прямое переливание крови", минуя винт. Спросили разрешения. Сначала я сунул свою флешку, через скунду -- партнер. Определить момент когда комп повесился (при втыкании какой флешки) -- как-то даже не обратили на это внимания. Только через несколько секунд стало ясно -- висит. Мертво!

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

Самое странное. Мать оказалась жива. Произошло что-то очень забавное на винте, т.к. после переустановки винды, все проблемы ушли. А я через день я получил соответствующую порцию негатива от хозяина компа за свою "кривую" флешку. (Хотя не факт, что винду убила моя!)

Мне, вот, интересно. Линуксоводы на форуме есть, наблюдается что-нибудь подобное у вас?

Теоретически [ ] такие глюки возможны и в Linux'е, вопрос в том что они будут моментально отловлены и менее чем за сутки будет выпущено исправление, дабы оное безобразие никогда больше не повторилось. Любителям остальных ОС можно порекомендовать техподдержку

Стоп, стоп! Уважаемый колега. Давайте не спеша пройдемся по механизму получения данных от устройств.

Допустим, драйвер создает переменную размереом 13 байт на стеке. Далее следует процесс копирования в нее 14 байт. Я хотел бы более подробно остановиться на этом.

Есть, собственно, два мехпанизма копирования -- аппаратный и программный. Рассмотрим оба. Для начала рассмотрим аппаратный, как наиболее вероятный. (К сожалению, я точно не знаю, что там конкретно происходит. Надеюсь, что знающие люди поправят.)

Итак, ПДП. Мы заказываем контроллеру ПДП 13 байт и получаем из южного моста посылку в 13 байт и аппаратное прерывание о том, что данные получены. Тринадцать байт -- ни больше, ни меньше. Так устроен ПДП. Что же касается 14-го байта, то он остается в аппартном буфере моста. Возможно, он помешает при следующем копировании. Но самое главное, ни о каком превышении размера, ни о каком "выезде" за границы массива, нет и речи. Стек цел и невредим. Еще раз повторю, что мне кажется, именно так и происходит получение данных от устройства в драйвер винды.

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

Хорошо. Продожаем. Что делать, если в драйвере возникла такая ситуация? Ронять ОСь? Может просто передать "на верх" состояние ошибки? Для этого у драйверов есть мехнизм. Какие проблемы?

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

Тема интересная. Если есть что сказать, говорите. А я сейчас наверно попытаюсь выкроить время -- полезу в книжку разбираться.



Извините, коллега, вопрос не в том, что "за сутки или за пол-года".

Вопрос в том -- реально (не теоретически!) наблюдаются-ли в других ОСях (в Linux'е, в частности) такие же явления с USB-устройствами?

Это не статика, а разность потенциалов между стыкуемыми девайсами. При подключении Вы их выравниваете, так сказать.


Чтобы не было уравнительных токов в момент подключения.

PS. Бывает еще веселее, если нет евророзеток. Меряешь напряжение между корпусами компов, а там хорошее напряжение.

В похожих ситуациях на Linux отваливается только флешка. Часто возникающая ситуация дома при втыкании плеера со встроенным аккумулятором. Решается перевтыканием флешек в другой последовательности. Отвалится может любой девайс. Если отвалилась смонтированная флешка - данные теряются.
При таком-же втыкании того-же оборудования в тот-же комп под виндой (XP Pro) - виснет и на ресет не реагирует. Спасает только полное отключение питания с выниманием из розетки удлинителя, к которому подключено все, что подключено к компу (системник, монитор, принтер, акустика ...).

Про остальные ОС не в курсе, но в Linux'е такое наблюдаться никак не может. Как уже было сказано - неверно работающее устройство будет остановлено с выводом сообщения о причине остановки в kernel log. При задании нужного уровня отладки для xhci_hcd, usbcore или конкретного драйвера usb устройства можно увидеть _весь_ протокол обмена с глючным USB устройством, что собственнно и рекомендовалось для отладки подобных девайсов.