Atridies 0 29 июня, 2014 Опубликовано 29 июня, 2014 (изменено) · Жалоба Есть плата с микроконтроллером STM32F107RB. Поставил стек LwIP, обрезал лишнее, но запустить не получается. Не принимает входящие пакеты. Данные на шине RMII - есть (CRS_DV, RXD0/1 - ведут себя вроде правильно). Настройка от порта LwIP - тоже вроде верная (уверен не на 100%, т.к. по битам регистров ETH - не гуру). Но какой бы пакет не передавал (ping или TCP) - статистика не увеличивается. При этом - отправка пакета - вроде идёт правильно (статистика увеличивается, но в сниффере - пока не смотрел). Насколько я понял по описанию - в случае отбраковки по какому-либо параметру на уровне MAC: все равно я должен иметь увеличивающуюся статистику. Поставил loopback на MAC, дают передачу пакета - все равно статистика приема - не увеличивается. Далее - значения всех регистров MAC и ETH_DMA: www[0] = ETH->MACFFR; // 0000 0000 www[1] = ETH->MACFCR; // 0000 0000 www[2] = ETH->MACRWUFFR; // 0000 0000 www[3] = ETH->MACSR; // 0000 0000 www[4] = ETH->MACIMR; // 0000 0000 www[5] = ETH->MACA0HR; // 8000 0100 // 01.00.00.00.00.00.00 - MAC-адрес изделия. // Сделаем 00.D0.59.12.32.5B. www[6] = ETH->MACA0LR; // 0000 0000 www[7] = ETH->MACA1HR; // 0000 FFFF www[8] = ETH->MACA1LR; // FFFF FFFF www[9] = ETH->MACA2HR; // 0000 FFFF www[10] = ETH->MACA2LR; // FFFF FFFF www[11] = ETH->MACA3HR; // 0000 FFFF www[12] = ETH->MACA3LR; // FFFF FFFF www[13] = 0xA3FFFFA0; www[14] = ETH->MMCCR; // 0000 0000 www[15] = ETH->MMCRIR; // 0000 0000 // Прерываний по статистике приема - не было. www[16] = ETH->MMCTIR; // 0000 0000 // Прерываний по статистике передачи - не было. www[17] = ETH->MMCRIMR; // 0000 0000 // Прерывания разрешены ? www[18] = ETH->MMCTIMR; // 0000 0000 // Прерывания разрешены ? www[19] = ETH->MMCTGFSCCR; // 0000 0000 // Количество переданных фреймов в HalfDuplex после одной коллизии. www[20] = ETH->MMCTGFMSCCR; // 0000 0000 // Количество переданных фреймов в HalfDuplex после нескольких коллизий. www[21] = ETH->MMCTGFCR; // 0000 0001 // !!!___ Количество удачно переданных фреймов. www[22] = ETH->MMCRFCECR; // 0000 0000 // !!!___ Количество принятых фреймов с ошибкой CRC. www[23] = ETH->MMCRFAECR; // 0000 0000 // !!!___ Количество притяных фреймов с ошибкой выравнивания. www[24] = ETH->MMCRGUFCR; // 0000 0000 // !!!___ Кол-во хороших принятых фреймов с unicast. www[25] = 0xA3FFFFA0; www[26] = ETH->DMABMR; // 0002 0100 www[27] = ETH->DMATPDR; // 0000 0000 www[28] = ETH->DMARPDR; // 0000 0000 www[29] = ETH->DMARDLAR; // 2000 A930 www[30] = ETH->DMATDLAR; // 2000 A970 www[31] = ETH->DMASR; // 0066 0404 www[32] = ETH->DMAOMR; // 0000 2002 www[33] = ETH->DMAIER; // 0001 0040 www[34] = ETH->DMAMFBOCR; // 0000 0000 www[35] = ETH->DMACHTDR; // 2000 A980 www[36] = ETH->DMACHRDR; // 2000 A930 www[37] = ETH->DMACHTBAR; // 2000 C740 www[38] = ETH->DMACHRBAR; // 2000 A990 Где может быть отброс пакета ? Вообще как-то можно узнать: данные с RMII - поступают на вход MAC ? Изменено 30 июня, 2014 пользователем IgorKossak [codebox] для длинного кода, [code] - для короткого!!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба у LwIP есть встроенная диагностика, если включить ее на полную, вас завалит сообщениями что происходит, какие пакеты пришли и почему они не понравились. Обычно отладка идет в порт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба Где может быть отброс пакета ? Вообще как-то можно узнать: данные с RMII - поступают на вход MAC ? Там есть так называемый драйвер Ethernet MAC, в нём пакеты и принимаются. К примеру, у меня есть такой кусок кода: p = low_level_input(); if (p) { ethernet_input(p, mynetif); } Если поставить точку останова на ethernet_input(), то в отладчике можно увидеть каждый принятый пакет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Atridies 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба Там есть так называемый драйвер Ethernet MAC, в нём пакеты и принимаются. К примеру, у меня есть такой кусок кода: p = low_level_input(); if (p) { ethernet_input(p, mynetif); } Если поставить точку останова на ethernet_input(), то в отладчике можно увидеть каждый принятый пакет. Еще раз проверил - проблема не в драйвере MAC. Проблема в железе MAC. Прием пакета идет следующим образом (вызовы функций): ETH_IRQHandler -> LwIP_Pkt_Handle -> ethernetif_input -> low_level_input -> ETH_RxPkt_ChainMode. Так вот: прерывания по ETH_IRQHandler - нету. Более того, регистры статистики в MAC (MACMMC) - не увеличиваются. Но данные на RMII - есть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба Проблема в железе MAC. Если точнее, то проблема в софте, как обычно. Вы, случайно, не используете код для режима MII? Потому что в режиме RMII есть одна маленькая особенность. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bureau 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба Atridies Вы re-map пинов верно провели? Откуда код брали? Сами с нуля подкручивали LwIP или брали пример с какой-то dev-board? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrewlekar 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба У меня в своё время на прерывания драйвер тоже не заработал (LPC1768). Разбираться особо не стал и сделал на поллинге очереди DMA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Atridies 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба У меня в своё время на прерывания драйвер тоже не заработал (LPC1768). Разбираться особо не стал и сделал на поллинге очереди DMA. 1. Проверил еще раз ремап. Все нормально. У меня ремапится только SPI1, и он не попадает на ножки с RMII. Проверил настройку режимов пинов - тоже все нормально. 2. ПО взял из примера от ST-microelectronics: это был http-сервер с lwip. Лишнее выбросил и прикрутил к своей программе. Так что это - частично мое, а в основном - из примера. Работу этого стека - я с devboard не проверял, ввиду отсутствия оной. 3. В этом примере была переключалка: MII/RMII. Она стоит на RMII. Судя по коду: dribble bit - не проверяется. Но даже если бы и проверялся - у MAC есть счетчик, который считает пакеты с ошибочным dribble bit (ETH_MMCRFAECR). А он у меня все время в нулях. 4. Странно, что прерывания не работают. Ну даже если так - статистика должна идти или нет? Я если честно уже запутался. 5. Еще никак не могу понять - где посмотреть: вообще в MAC приходят пакеты или нет? Пусть битые, чужие, пусть прерывания не так работают. Хоть какие-нибудь... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bureau 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба Была подобная проблема -- не приходили прерывания. Деталей не помню, но точно искал причину отсутствия прерываний. На какой адрес настроена физика? (в железе и программе, значения совпадают?) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба На какой адрес настроена физика? (в железе и программе, значения совпадают?) Адресация есть на шине SMI. У интерфейса RMII никакой адресации нет. Так что совсем не в тему. Кстати, возможны банальные ошибки в схемотехнике, если плату сами делали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
doom13 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба Вы, случайно, не используете код для режима MII? Потому что в режиме RMII есть одна маленькая особенность. Если можно, тут по-подробнее, где искать и его название в либе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 30 июня, 2014 Опубликовано 30 июня, 2014 · Жалоба у меня глупый вопрос, а вы в МАК контроллер мак адрес передали? Может пакеты просто по этому параметру отфильтровываются? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Atridies 0 2 июля, 2014 Опубликовано 2 июля, 2014 · Жалоба Проблема решилась. Дело было в неправильной настройке MAC. Не совпадала скорость и еще некоторые параметры. Дело в том, что в примере был косячок: настройка PHY не производилась, если не подключен кабель. Я это махнул из программы, а заодно зацепил некоторые настройки. Всем спасибо ! P.S. Теперь, Слава Богу, более-менее понимаю, как работает MAC. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
fault-tolerant 0 22 декабря, 2014 Опубликовано 22 декабря, 2014 (изменено) · Жалоба Проблема решилась. Дело было в неправильной настройке MAC. Не совпадала скорость и еще некоторые параметры. Дело в том, что в примере был косячок: настройка PHY не производилась, если не подключен кабель. Я это махнул из программы, а заодно зацепил некоторые настройки. Всем спасибо ! P.S. Теперь, Слава Богу, более-менее понимаю, как работает MAC. Очень хотелось бы, если можно, чуть чуть поподробнее. Мучаюсь с STM32F207, плата наша, разработана по примерам ST и Micrel, PHY - KSZ8051RNL. RMII в виду того, что много IO нужно было... И работает в принципе, только передавая файлы, как картинки по HTTP, или, на пример, в тестовой программе IPREF, вдруг виснет секунд на 15, тупо пережевывая склиентом один и тот же пакет. Клиент грит - ты проустила пакет номер такой-то, верни! А плата: на! А пакет не тот... А через 15 секунд примерно отпускает - но только на секунду, потом опять. Прилагаю картинку. Уже чего только в параметрах стандартного ST-шного драйвера не менял, все регистры проверял, и MAC и PHY... Вроде "ETH_DMAMFBOCR" насчитывает непринятые пакеты, но настройки, с ним связанные, не помогают. Может что у вас подберу по настройкам? Проблема не в программе, так как то же самое происходит в совершенно разных примерах, с LwIP, с NetX. Спасибо! Изменено 22 декабря, 2014 пользователем fault-tolerant Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 22 декабря, 2014 Опубликовано 22 декабря, 2014 · Жалоба вроде пакетами это уже уровень выше мака и физики, сильно выше, это даже не IP а TCP уже... точно не стэк виноват? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться