Доброго времени суток. Собрал плату на Ksz8041, STM32F4 + LwIP. Подправил пример стека - "под себя". Столкнулся с тем, что через 100Мбитный хаб ничего не работает, а на прямую через сетевой switch все работает как должно. У PHY включен "Auto-Negotiation" внешней подтяжкой, пробовал так же программно, разницы нет. Link устанавливается, стек пакеты принимает (видно в буфере и по прерыванию Ethernet) и передает (заметна активность TXD0-1 CRS_DV), но wireshark ничего не видит.

Увы не до конца понятен алгоритм с Auto-Negotiation, так же не ясно какой из регистров должен давать информацию (1,4 или 5) и нужно ли вручную конфигурировать PHY ?
Кто сталкивался ..., отзовитесь пожалуйста ...

пробовал вручную заполнять структуру ETH_InitStruct, ставил 10-100 Full-HalfDuplex, результата нет

Скорее всего, PHY здесь ни при чем. Есть два варианта - или проблемы с частотой (точности недостаточно) и хаб не принимает пакеты. При этом лампочка на хабе может моргать правильно. Второй вариант - ошибки в пакетах с MAC-адресами. Например, пинг-пакет с широковещательным MAC'ом.

KSZ8041 не использовал, а вот KSZ8031 и KSZ8863 да, были проблемы с "Auto-Negotiation". Поборол так:
- в структуре инициализации поставил "ETH_InitStructure.ETH_AutoNegotiation = ETH_AutoNegotiation_Disable;";
- в файле "stm32f4x7_eth.с" , в блоке условия проверки
"if(ETH_InitStruct->ETH_AutoNegotiation != ETH_AutoNegotiation_Disable)
{ ....}
else{.."
поставил явно инициализацию физикса
ETH_WritePHYRegister(PHYAddress, PHY_BCR, 0x2100); //FullDuplex 100M
ETH_InitStruct->ETH_Speed = ETH_Speed_100M;
ETH_InitStruct->ETH_Mode = ETH_Mode_FullDuplex;

Значение PHY_BCR привёл для KSZ8031, у Вас может быть другое.

Оказалось у меня PHY работает не со всеми сетевыми картами. В локалке через switch работает нормально, а уже через switch другой марки - пакеты не пропускаются, так же и с компьютером - на ноутбуке пакеты принимаются, а на компьютере уже нет ( Подогнал токозадающее сопротивление до единиц ом, проверил всю схемотехнику, разницы пока не заметил. Самое интересно, что пакеты время от времени таки пролетают, но очень редко (~1 пакет в 3 минуты)
Причем Autonegatioation определяет все как надо, биты "доступности" 100-F-H, 10-F-H выставлены

"не пропускаются" - это откуда, куда, тип протокола в пакете???

согласитесь - если пакет один в один с "хорошим", то фокусов не должно быть.
ищите отличия. проверьте MAC-и, IP-шники, прохождение ARP запрос-ответов...

что стоит в "локалке" - это типа хаб или свитч другой марки? Настройки свитча существуют или нет? Если да - то разрешено ли там усё???

вопросов больше чем ответов.
что видит анализатор? пытались ли сравнивать "хорошие" пакеты и "плохие"?

PHY может быть просто криво подключен (питание, земли и т.д.).
И ещё бы добавил возможность ошибок по длине фреймов. Но это уже менее вероятно, таки постараться надо. Впрочем, ТС стек перепиливал, так что мог.
Если бы делали ставки, я бы поставил на проблемы с клоками. 4 к 1-му. Что-то мне подсказывает...



Если речь о локалке, т.е. свитчевание чисто по L2, то протокол как бы без разницы. При корректно сформированном пакете, ессно.
Но статистику посмотреть стоило бы, это да.

Спасибо за внимание. Разобрался. Безумно стыдно и радостно ) Проблема оказалась в тактировании. Брал от MCO (PLL/3) = 50 Мгц.
Подвинул бит делителя и пакеты пошли в сеть. Буду ставить кварцевый генератор

Рекомендую следующий алгоритм реализации той или иной обвязки...
Смотрите, что нить многофункциональное(демоборд) на Ваш МК. Чтоб там были куча-куча перефирии на все случаи жизни
(ну или под будущий Ваш проект). Тупо покупаете. Тупо добиваетесь работоспособности прошивки тех исходников, что поставляются
как примеры вместе с железкой. Тупо гоняете железо в тех режимах, что интересны Вам. Тупо срисовываете схемное решение и разводку.
Тупо заказываете детали. Вдумчиво переписываете по желанию софт на боевой (с копанием в даташитах и исправлением баг
от производителя. Увы они бывают частенько). Собираете свою железку. Профит.

Тем самым Вы исключаете долгое ковыряние с новой для Вас темой и имеете быстрый старт-ап боевого железа.
При этом Вы всегда идёте вперёд, опираясь на предыдущий результат наращивая свои знания и опыт.

Спасибо. В целом стараюсь так и делать. Но вот коснулся STM32F4, решил борду не покупать, так как отличия от STM32F2xx показались не столь большими. А вот схему срисовал с демоборды, правда там использовался MII, внешний генератор и PHY был один из самых дорогих )
Не подскажете пожалуйста, как может называться - низкоуровневый Ethernet сниффер?
На этом проекте по прежнему остается чудовищный баг, при котором через 5-10 минут MAC продолжает слать пакеты, но в сети они уже не проходят или не появляются ... При этом прием происходит без изменений. Перерыл все исходники, пробовал найти проблему но так и не получилось. Буфер и дескриптор заполняются без ошибочно, у MAC DMA все указатели на буфера так же верные. Содержимое регистров MAC и MAC DMA не отличаются до и после бага. На выводах TXD0-1 так же проявляется активность при отправке, а Wireshark-ом уже не видно ...
Не понимаю, возможно пакет отправляется битым, возможно он не отправляется вовсе, но увидеть это нечем ...

Ниже Wireshark'а из PC не посмотрите. Карточка все битые пакеты выкидывает безоговорочно.

Специализированные сетевые анализаторы это умеют.

о как...

Юзал всегда Ethereal - там таких проблем не замечено. Все программерские ошибки в ввиде битых пакетов видны на ура...

Всегда ваершаку не доверял...




всегда юзал Ethereal. Он точно показывает всё что послано в сеть. Т.е. не опознанные, битые, ошибочные с точки зрения формата
и с точки зрения протокола.
Если ваеришак глючит - то это дерьмо а не снифер(сам его не юзал - хз)... Но подозреваю что всё-таки проблема в передатчике.
Попробуйте в обработчике передатчика подсчитывать реально поставленных на передачу в железо пакеты. И на более высоком уровне
- переданных на саму передачу. Или по другому - как Вы контролируете что передача происходит? Проверяли ли отладчиком
обработку прерывания передатчика(окончания передачи ПДП)? Там всё корректно? Как Вы отрабатываете сборку DMA отработанных
сегментов? Там всё корректно(возвращается ли память обратно в свободный пул, корректна ли обработка нехватка памяти и нет ли
зависимости обработчика прерывания от тяжёлых функций)? В своё время меня не устроил обработчик по умолчанию - дюже тяжёл был.
Пришлось доводить до ума.

Смотрю отправку в:
После старта, без появления глюка, данные отправляются сразу после ETH->DMATPDR = 0;, как и должно.
После проявления глюка, светодиод на разъеме LAN так же "моргает" после записи нуля в DMATPDR, т.е. что-то через физику уходит.
В регистре DMASR, разницы с проявлением глюка - не вижу.
Биты TPS, NIS, ETS выставляются так же.
в MMCTGFCR (transmitted good frames counter register) после записи DMATPDR счет так же увеличивается ...
Честно говоря уже голову сломал, больше недели потратил - результат пока нулевой (
Думаю стек и драйвер от st не при делах.
Сверял все указатели непосредственно в регистре DMA, указатели на дескрипторы и их содержимое, на буфер Tx, все верно и не отличается от работы до появления этого глюка.
Думаю если создать свой буфер с дескриптором (да заполнить константами) и подцепить к DMA вместо буфера из стека, наверняка получится то же самое ...
Уже и Errata на STM32F429 пересмотрел, ничего похожего не нашел, что не удивительно.

Не совсем так. Он не глючит. Все неверные пакеты с точки зрения формата он покажет. Но если пакет в проводе с неверной контрольной суммой Ethernet, то его не примет карточка и никто, кроме аппаратного анализатора не покажет, где ошибка. Максимум, что можно получить в этом случае - счетчик битых пакетов.

если под контрольной суммой подразумевается любая протокольная (MAC и выше) - то БРЯХНЯ....

лично сам из опыта имею другие данные.
давно, в процессе запуска TCP/IP стека на 51 серии допускал и такие ошибки - сами пакеты ловились на ура Ethereal-ом.
Допускаю, что Вы имели опыт работы с другими конфигурациями топологии сети и(или) другими карточками.
Посему Ваше заявление о "ни кто" - не совсем истина.

PS
Если Вы тестировали в стандартном сегменте сети - то понятна причина Свитчи имеют маршрутизацию на втором
мак уровне(как правило), отгадайте как это решается задача и весь ли мусор они обязаны перенаправлять?

Я же специально написал - Ethernet контрольная сумма, самая нзкоуровневая. Все остальное, естественно, принимается.

Да, в соответствии с 802 и иже их, такие пакеты должны дропаться. Т.е., для стандартной настройки так и будет. Но возможность настройки MAC для принятия битого пакета - весьма распространённая фича. Существует даже целый класс сетевого оборудования, который в принципе рссчитан на работу с битыми контрольными суммами.

Расшифруйте термин "низкоуровневая"...

Если это уровень MACа - то я уже выше И ПРО НЕГО так-же сказал = принимаются на ура, при правильном подключении и софте.

IEEE 802.3 MAC frame format - Frame check sequence.