При 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) - и приложение будет с позором выдворено из системы. А на уровне ядра на исключения не всегда приходится рассчитывать, особенно в процедурах обработки прерываний, где код драйвера выполняется на высоких приоритетах ...