Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: LPC + Ethernet
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
0000h
Имею отладочную плату для микроконтроллера LPC1768, на которой в числе прочих разъёмов и кнопок имеется ethernet-розетка (в качестве PHY напаяна DP83848). Выкурил datasheet'ы и reference manual на указанный ARM камень и PHY, в итоге - запустил ethernet: приём, передача, с прерываниями и без, как угодно. Плату подключаю в домашнюю локалку через маршрутизатор (DIR-320 c DHCP, IP-адрес платы статический). Так вот, проблема в том, что при отправке UDP-пакета на IP-адрес платы виндовый драйвер, естественно не зная MAC-адрес платы сначала посылает в сеть ARP-запрос, который моя плата прекрасно ловит и отправляет ответ (мониторю с помощью WireShark). Затем по логике должен следовать исходящий UDP-пакет, но его нет! Хотя в программе, отправляющей UDP-пакет, функция sendto возвращает как и положено кол-во отправленных байтов! Но пакета нет - ни монитор, ни плата никак не реагируют!
Что за... angry.gif Смотрю ARP-кэш - там только MAC-адрес маршрутизатора. Руками в кэш прописываю IP и MAC платы. Повторяю отправку UDP-пакета. И вот тут-то уже UDP проскочил и в WireShark, и в плате.
Знающие люди, подскажите почему ответ на ARP-запрос с компа не записался в кэш и почему драйвер винды так подло шутит, возвращая положительный ответ, хотя на самом деле ничего не отправлял?
Cosmojam
Проверяйте внимательно корректность ответного ARP пакета.
Драйвер винды не шутит. UDP в самом названии содержит ответ. UDP и ни один из ниже лежащих протоколов ничего знать не знает об успешности отправки пакета. Попробуйте сделать sendto() на любой немыслимый адрес:порт и она вернёт успешную отправку если никаких других ошибок не было.
_Артём_
Цитата(Cosmojam @ Jul 23 2012, 00:56) *
Попробуйте сделать sendto() на любой немыслимый адрес:порт и она вернёт успешную отправку если никаких других ошибок не было.

Но пакет-то должен быть послал? А чтобы его послать нужен MAC, а значит перед UDP будет послан ARP. Разве нет?
Cosmojam
Цитата(_Артём_ @ Jul 23 2012, 02:05) *
Но пакет-то должен быть послал? А чтобы его послать нужен MAC, а значит перед UDP будет послан ARP. Разве нет?

По логике да, но это фича UDP+ARP http://www.pcvr.nl/tcpip/udp_user.htm sendto(). Можно использовать виндовую функцию SendARP перед отправкой UDP чтобы убедиться в наличии адреса в ARP кэше. Но я так не пробовал делать, точнее не скажу.
0000h
Спасибо за подсказки, проблема была в том, что я неверно формировал ответ на ARP-запрос (перепутал местами поля MAC,IP для Target и Source). Но в процессе исследований выяснилась ещё одна неприятная деталь. Оказалось, что регистр приёмника RxProduceIndex при приёме первого пакета не инкрементируется и прерывание не возникает, хотя принятый пакет в буфер дескриптора кладётся. Кто-нибудь с таким сталкивался?
theBMV
Цитата(0000h @ Jul 23 2012, 22:27) *
Спасибо за подсказки, проблема была в том, что я неверно формировал ответ на ARP-запрос (перепутал местами поля MAC,IP для Target и Source). Но в процессе исследований выяснилась ещё одна неприятная деталь. Оказалось, что регистр приёмника RxProduceIndex при приёме первого пакета не инкрементируется и прерывание не возникает, хотя принятый пакет в буфер дескриптора кладётся. Кто-нибудь с таким сталкивался?

В ERRATA этот момент описан уже очень давно.
ibiza11
Прошу прощения за некропостинг, но насколько я знаю, этот момент не описан. Описана проблема с TxConsumeIndex. Но не с RxProduceIndex.
theBMV
Цитата(ibiza11 @ Jun 10 2013, 09:43) *
Прошу прощения за некропостинг, но насколько я знаю, этот момент не описан. Описана проблема с TxConsumeIndex. Но не с RxProduceIndex.


Да, ошибся, не посмотрел.
Так ведь инкрементировать Produce индексы - дело как раз таки обработчика, а не периферии.
ibiza11
Опять неправда. DMA инкрементирует TxConsumeIndex и RxProduceIndex. Обработчик - TxProduceIndex и RxConsumeIndex
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.