При USB соединении с AT91SAM7S256 перегружается комп!, в чём может быть проблема? Опции

[vdik]

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

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

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

[sergeeff]

Коллеги!

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

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

[Demeny]

Кстати меня это наводило на грустные мысли по поводу всяких там идей про ring0 - ring3 защиты в OC и прочие прибамбасы. Летит все сразу к чертям.

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

[zhevak]

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

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

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

[Demeny]

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

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

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

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

[zhevak]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Harbour]

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

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