USB Device на AT91SAM7, Насколько сложно и что нужно Опции

[Eduard_k]

Добрый день,

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

1. Есть ли где-нибудь полное описание USB 1.0 на русском языке, т.к. если например с RS-232 в абсолютно ясно то USB является для многих "черным ящиком", непонятно как работает устройство, как работает компьютер.
2. Насколько сложно написать ПО для контроллера и ПК человеку который владеет C++ но едва знает AT91SAM7 и вообще не знает USB. Сколько приблизительно займет это времени?
3. Какие готовые програмные модули мне понадобятся? Где их взять?
4. Как сделать так чтобы контроллер питался от шины USB? Меня смущает тот факт, что контроллер будет работоспособен приблизительно через 0.8 сек. после того как устройство уже будт воткнуто в порт. Нет ли проблемы в том, что питание на контроллере появится после появления сигналов D+ D- на выводах.

Спасибо

[Dron_Gus]

Я с DriverStudio тоже долго бодался. Даже не пытался получать конфигурацию из устройства - вводил вручную. Заставить работать с VisualStudio 2000 и выше не получилось. Заработало лишь с VC++ 6.0. После установки DDK (последняя версия на microsoft.com) в VC++ надо компильнуть библиотеки для соответствующей версии виндов (build -cZ). После установки DriverStudio в VC++ должна появится новая панель. Там настройка DriverStudio, запуск помошника и ГЛАВНОЕ кнопка "компилировать с помошью DDK".

[AVR]

Dron_Gus, большое спасибо за помощь, действительно с VS 6 и последней DDK всё собралось

[AVR]

Подскажите, пожалуйста, как отлаживать драйвер, если при обращении к некоторым его функциям возникают BSOD? У меня появляется такая ошибка KERNEL_MODE_EXCEPTION_NOT_HANDLED, пишет что

If exception code 0x80000003 occurs, this indicates that a hard-coded breakpoint or assertion was hit, but the system was started with the /NODEBUG switch. This problem should rarely occur. If it occurs repeatedly, make sure a kernel debugger is connected and the system is started with the /DEBUG switch.

Если запускаю WinXP с ключем /DEBUG - просто виснет... Можно ли настроить так, чтобы при исключениях или ошибках не вешалось вообще всё?
Например, обработчик функции WriteFile или ReadFile работает до тех пор пока не дойдет до BuildBulkTransfer, но как выяснить причину ошибки - непонятно...

[sff]

Подскажите, пожалуйста, как отлаживать драйвер, если при обращении к некоторым его функциям возникают BSOD? У меня появляется такая ошибка KERNEL_MODE_EXCEPTION_NOT_HANDLED, пишет что

If exception code 0x80000003 occurs, this indicates that a hard-coded breakpoint or assertion was hit, but the system was started with the /NODEBUG switch. This problem should rarely occur. If it occurs repeatedly, make sure a kernel debugger is connected and the system is started with the /DEBUG switch.

Если запускаю WinXP с ключем /DEBUG - просто виснет... Можно ли настроить так, чтобы при исключениях или ошибках не вешалось вообще всё?
Например, обработчик функции WriteFile или ReadFile работает до тех пор пока не дойдет до BuildBulkTransfer, но как выяснить причину ошибки - непонятно...

Ну, во-первых, синие экраны отключить нельзя, на то они и синие экраны. Значит уже что-то произошло с чем система никак не может справится (сбой общей защиты и тп).
А отладка ядра (с ключём /DEBUG ) это не совсем то что в вижуал студии отладка. При этом нужно 2 машины, соединеённые по COM порту (в вин 2000 было только так) и если что повиснет на отлаживаемой то можно оттрапить на другой и посмотреть в каком месте.
Посмотрите поподробнее в DDK Using Microsoft Debugger (WinDbg, KD).
Если включить посмертный dump то можно с помощью этих утилит посмотреть в каком месте драйвера произошел exception.
Также неплохая программка была Марка Руссиновича LiveKD которая позволяля гулять по ядру на самой машине но только когда система не екнулась =)
А так, кстати, неплохая у него и книга про внутреннее устройство виндоус, хоть там про написание драйверов ничего нет, но общее представление даёт неполохое.

[AVR]

Ну, во-первых, синие экраны отключить нельзя, на то они и синие экраны.

В хелпе к WinDbg написано:

If a kernel debugger is attached and active, the system causes a break so the debugger can be used to investigate the crash.
If no debugger is attached, a blue text screen appears with information about the error. This screen is called a blue screen, a bug check screen, or a Stop screen.

т.е., насколько я понял, если запущен отладчик, то вместо синего экрана должно что-то появиться в окне отладчика. Я пробовал запустить локальный kernel debug и соединился по TCP с другого компьютера, однако по-прежнему просто виснет намертво и ничего не пишется ни на локальном компьютере, ни на удаленном... Может чего не так делаю?... Или в программе драйвера нужно как-то обрабатывать исключительные ситуации?

[sff]

Ну, во-первых, синие экраны отключить нельзя, на то они и синие экраны.

В хелпе к WinDbg написано:

If a kernel debugger is attached and active, the system causes a break so the debugger can be used to investigate the crash.
If no debugger is attached, a blue text screen appears with information about the error. This screen is called a blue screen, a bug check screen, or a Stop screen.

т.е., насколько я понял, если запущен отладчик, то вместо синего экрана должно что-то появиться в окне отладчика. Я пробовал запустить локальный kernel debug и соединился по TCP с другого компьютера, однако по-прежнему просто виснет намертво и ничего не пишется ни на локальном компьютере, ни на удаленном... Может чего не так делаю?... Или в программе драйвера нужно как-то обрабатывать исключительные ситуации?

Ну отладку я подразумевал как логическое продолжение BSOD =)

А вот про TCP поподробнее.. Это в WinXP появилось? У меня просто DDK от 2000
Я делал так, соединял 2 компа нуль-модемным и отлаживаемый грузил с /DEBUG /debugport=com1

Хотел щас проделать тоже самое на XP но так как DDK от 2000 не получилось =( После того как распознал что на таргет машине XP вывалился.

[AVR]

А вот про TCP поподробнее.. Это в WinXP появилось?

Скорее всего ничего не появилось, а я что-то недопонял. Я имел ввиду в WinDbg установил TCP соединение... Наверное это совсем не то что нужно...
PS
В хелпе на DriverWorks наткнулся на следующее:

The KException class translates a Structured Exception (SE) raised by the kernel into a C++ exception. This allows to treat a SE as a C++ exception to catch both kernel-raised and user-defined exceptions.

Это, случайно, не для того чтобы не доводить дело до синего экрана?.. Чтобы это использовать требуется файл CppExcpt.lib, однако найти его нигде так и не удалось...

[sff]

Скачал я WinXP DDK и оказывается кое-что всё-таки добавили Появилась возможность отладки по IEEE1394 и USB2.0 с волшебным девайсом.
Опишу соединение по COM порту
1. На таргет машине в C:\boot.ini добавляю запуск системы с опциями /DEBUG /debugport=com1 (допустим копирую первую системы и вставляю на следущую строчку добавляя данную конструкцию). Будте осторожны если повредить этот файл то может система вообще не загрузится
2. Соединяются хост и таргет машины нуль-модемным кабелем
3. Запуская на хост машине WinDbg. File-> Kernel Debug... Выбираю вкладку COM, пишу соответствующий COM порт, задаю baudrate 19200 (именно такой используется по дефолту, его можно изменить задав опцию /baudrate=xxxxxx в boot.ini на таргет машине). И ставлю галочку reconnect. Ok.
4. Запускаю хост машину, выбрав из списка конфигурацию с отладкой. Грузится будет дольше, даже гораздо дольше и когда-то напишет что-то наподовие

Код

Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420

Ну и после загрузки или во время можно попытаться скормить заведомо глючный драйвер и вот что появится:

Код

*** Fatal System Error: 0x000000d1
                       (0x00000000,0x00000002,0x00000001,0xF9C6B67D)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
*                                                                   *
* The Symbol Path can be set by:                                    *
*   using the _NT_SYMBOL_PATH environment variable.                 *
*   using the -y <symbol_path> argument when starting the debugger. *
*   using .sympath and .sympath+                                    *
*********************************************************************
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntoskrnl.exe -
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {0, 2, 1, f9c6b67d}

ANALYSIS: Kernel with unknown size. Will force reload symbols with known size.
ANALYSIS: Force reload command: .reload /f ntoskrnl.exe=FFFFFFFF804D7000,213F80,42250FF9
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for NDIS.sys -
*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys
*** ERROR: Module load completed but symbols could not be loaded for DP83815.SYS
Probably caused by : DP83815.SYS ( DP83815+267d )

Followup: MachineOwner
---------

nt!DbgBreakPointWithStatus+0x4:
804e3592 cc              int     3

Для более подробной информации можно набрать !analyze -v

Код

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f9c6b67d, address which referenced memory

Debugging Details:
------------------

ANALYSIS: Kernel with unknown size. Will force reload symbols with known size.
ANALYSIS: Force reload command: .reload /f ntoskrnl.exe=FFFFFFFF804D7000,213F80,42250FF9
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

***** Kernel symbols are WRONG. Please fix symbols to do analysis.


MODULE_NAME: DP83815

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4096c0df

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
00000000

CURRENT_IRQL:  2

FAULTING_IP:
DP83815+267d
f9c6b67d f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

DEFAULT_BUCKET_ID:  WRONG_SYMBOLS

BUGCHECK_STR:  0xD1

LAST_CONTROL_TRANSFER:  from 80532d2e to 804e3592

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
f9ce49e4 80532d2e 00000003 00000000 f9c6b67d nt!DbgBreakPointWithStatus+0x4
f9ce4dc4 804e187f 0000000a 00000000 00000002 nt!KeDeregisterBugCheckReasonCallback+0x6c7
f9ce4e64 f972cfca 00000000 819e8000 00000000 nt!Kei386EoiHelper+0x2823
f9ce4e88 804dc4fd 819e82b8 819e8290 eb370870 NDIS!NdisMSetTimer+0x90
f9ce4fa4 804dc378 0d839080 00000000 ffdff000 nt!KeSetTimer+0x113
f9ce4fd0 804dbbd4 80559280 00000000 000008d7 nt!KeWaitForMutexObject+0x1d8
f9ce4ff4 804db89e f9d188a0 00000000 00000000 nt!KiDispatchInterrupt+0x360
00000000 00000000 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a


STACK_COMMAND:  .bugcheck; kb

FOLLOWUP_IP:
DP83815+267d
f9c6b67d f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

FOLLOWUP_NAME:  MachineOwner

IMAGE_NAME:  DP83815.SYS

SYMBOL_NAME:  DP83815+267d

BUCKET_ID:  WRONG_SYMBOLS

Followup: MachineOwner
---------

Тут у меня ещё пути не все верно поставлены вот и ругается.
Как видно уже намного больше полезной инфы нежели в BSOD'е

Подробнее про отладку можно прочитать kernel_debugging_tutorial.doc из состава Debugging Tools for Windows

В хелпе на DriverWorks наткнулся на следующее:

The KException class translates a Structured Exception (SE) raised by the kernel into a C++ exception. This allows to treat a SE as a C++ exception to catch both kernel-raised and user-defined exceptions.

Это, случайно, не для того чтобы не доводить дело до синего экрана?.. Чтобы это использовать требуется файл CppExcpt.lib, однако найти его нигде так и не удалось...

Ну, скажем, лишь в некоторых случаях которые вам хорошо известны. Например при взаимодействием с пользователем, которые в вызове ioctl указал кривые адреса и их нужно поймать ACCESS_VIOLATION.
Ну и другого типа. А ловить всё подряд чтобы их не было это не лучшая затея. Так как могут быть исключеия для вас не предназначенные и они обрабатываются уровнем выше
Ну с DriverStudio я возился совсем чуть-чуть... и меня он не сильно впечатлил. Так что с этим помочь не могу.
Советую хоть посмотреть несколько глав про IRQL в MSDN или в книге Руссиновича. Многие сомнения на тему bsod и их появление пропадут.

[AVR]

sff, большое спасибо, ошибку свою нашел (полное просветление наступило после прочтения http://www.mqp.com/ums_4.htm ). Получилось 6,5 Мбит/с.
Как лучше всего переписать пример на работу через прерывания? Можно ли, например, использовать для этого какую-нибудь RTOS и останавливать поток работы с USB на время ожидания флагов приема/передачи/* и возобновлять его работу при возникновении прерывания от UDP?