Доброго времени суток. Собрал плату на 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, результата нет

Сообщение отредактировал khomin - Apr 12 2015, 14:34

Скорее всего, 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 выставлены

Сообщение отредактировал khomin - Apr 21 2015, 06:20

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

согласитесь - если пакет один в один с "хорошим", то фокусов не должно быть.
ищите отличия. проверьте 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-ом уже не видно ...
Не понимаю, возможно пакет отправляется битым, возможно он не отправляется вовсе, но увидеть это нечем ...

Сообщение отредактировал khomin - Apr 24 2015, 09:02

Ниже 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 пересмотрел, ничего похожего не нашел, что не удивительно.


Сообщение отредактировал khomin - Apr 25 2015, 19:28

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

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

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

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

Сообщение отредактировал kolobok0 - Apr 26 2015, 09:31