Jump to content

    
Sign in to follow this  
khomin

Ksz8041 не отправляет через Хаб

Recommended Posts

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

Edited by khomin

Share this post


Link to post
Share on other sites

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

Share this post


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

 

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, у Вас может быть другое.

Share this post


Link to post
Share on other sites
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 выставлены

Edited by khomin

Share this post


Link to post
Share on other sites
В локалке через switch работает нормально, а уже через switch другой марки - пакеты не пропускаются, ...

 

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

 

согласитесь - если пакет один в один с "хорошим", то фокусов не должно быть.

ищите отличия. проверьте MAC-и, IP-шники, прохождение ARP запрос-ответов...

 

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

 

вопросов больше чем ответов.

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

 

Share this post


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

 

PHY может быть просто криво подключен (питание, земли и т.д.).

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

Если бы делали ставки, я бы поставил на проблемы с клоками. 4 к 1-му. Что-то мне подсказывает...

 

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

...

 

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

Но статистику посмотреть стоило бы, это да.

Share this post


Link to post
Share on other sites
PHY может быть просто криво подключен (питание, земли и т.д.).

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

Если бы делали ставки, я бы поставил на проблемы с клоками. 4 к 1-му. Что-то мне подсказывает...

 

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

Но статистику посмотреть стоило бы, это да.

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

Подвинул бит делителя и пакеты пошли в сеть. Буду ставить кварцевый генератор

Share this post


Link to post
Share on other sites
Спасибо за внимание. Разобрался. ...

 

Рекомендую следующий алгоритм реализации той или иной обвязки...

Смотрите, что нить многофункциональное(демоборд) на Ваш МК. Чтоб там были куча-куча перефирии на все случаи жизни

(ну или под будущий Ваш проект). Тупо покупаете. Тупо добиваетесь работоспособности прошивки тех исходников, что поставляются

как примеры вместе с железкой. Тупо гоняете железо в тех режимах, что интересны Вам. Тупо срисовываете схемное решение и разводку.

Тупо заказываете детали. Вдумчиво переписываете по желанию софт на боевой (с копанием в даташитах и исправлением баг

от производителя. Увы они бывают частенько). Собираете свою железку. Профит.

 

Тем самым Вы исключаете долгое ковыряние с новой для Вас темой и имеете быстрый старт-ап боевого железа.

При этом Вы всегда идёте вперёд, опираясь на предыдущий результат наращивая свои знания и опыт.

 

Share this post


Link to post
Share on other sites
Рекомендую следующий алгоритм реализации той или иной обвязки...

Смотрите, что нить многофункциональное(демоборд) на Ваш МК. Чтоб там были куча-куча перефирии на все случаи жизни

(ну или под будущий Ваш проект). Тупо покупаете. Тупо добиваетесь работоспособности прошивки тех исходников, что поставляются

как примеры вместе с железкой. Тупо гоняете железо в тех режимах, что интересны Вам. Тупо срисовываете схемное решение и разводку.

Тупо заказываете детали. Вдумчиво переписываете по желанию софт на боевой (с копанием в даташитах и исправлением баг

от производителя. Увы они бывают частенько). Собираете свою железку. Профит.

 

Тем самым Вы исключаете долгое ковыряние с новой для Вас темой и имеете быстрый старт-ап боевого железа.

При этом Вы всегда идёте вперёд, опираясь на предыдущий результат наращивая свои знания и опыт.

Спасибо. В целом стараюсь так и делать. Но вот коснулся STM32F4, решил борду не покупать, так как отличия от STM32F2xx показались не столь большими. А вот схему срисовал с демоборды, правда там использовался MII, внешний генератор и PHY был один из самых дорогих )

Не подскажете пожалуйста, как может называться - низкоуровневый Ethernet сниффер?

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

Не понимаю, возможно пакет отправляется битым, возможно он не отправляется вовсе, но увидеть это нечем ...

Edited by khomin

Share this post


Link to post
Share on other sites
...

Не понимаю, возможно пакет отправляется битым, возможно он не отправляется вовсе, но увидеть это нечем ...

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

 

Share this post


Link to post
Share on other sites
Ниже Wireshark'а из PC не посмотрите. Карточка все битые пакеты выкидывает безоговорочно.

 

о как...

 

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

 

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

 

 

..возможно пакет отправляется битым, возможно он не отправляется вовсе, но увидеть это нечем ...

 

всегда юзал Ethereal. Он точно показывает всё что послано в сеть. Т.е. не опознанные, битые, ошибочные с точки зрения формата

и с точки зрения протокола.

Если ваеришак глючит - то это дерьмо а не снифер(сам его не юзал - хз)... Но подозреваю что всё-таки проблема в передатчике.

Попробуйте в обработчике передатчика подсчитывать реально поставленных на передачу в железо пакеты. И на более высоком уровне

- переданных на саму передачу. Или по другому - как Вы контролируете что передача происходит? Проверяли ли отладчиком

обработку прерывания передатчика(окончания передачи ПДП)? Там всё корректно? Как Вы отрабатываете сборку DMA отработанных

сегментов? Там всё корректно(возвращается ли память обратно в свободный пул, корректна ли обработка нехватка памяти и нет ли

зависимости обработчика прерывания от тяжёлых функций)? В своё время меня не устроил обработчик по умолчанию - дюже тяжёл был.

Пришлось доводить до ума.

 

 

Share this post


Link to post
Share on other sites
как Вы контролируете что передача происходит? Проверяли ли отладчиком

обработку прерывания передатчика(окончания передачи ПДП)? Там всё корректно? Как Вы отрабатываете сборку DMA отработанных

сегментов? Там всё корректно(возвращается ли память обратно в свободный пул, корректна ли обработка нехватка памяти и нет ли

зависимости обработчика прерывания от тяжёлых функций)? В своё время меня не устроил обработчик по умолчанию - дюже тяжёл был.

Смотрю отправку в:

    /* When Tx Buffer unavailable flag is set: clear it and resume transmission */
    if ((ETH->DMASR & ETH_DMASR_TBUS) != (u32)RESET)
    {
        /* Clear TBUS ETHERNET DMA flag */
        ETH->DMASR |= ETH_DMASR_TBUS;
        /* Resume DMA transmission*/
        ETH->DMATPDR = 0;
    }

После старта, без появления глюка, данные отправляются сразу после ETH->DMATPDR = 0;, как и должно.

После проявления глюка, светодиод на разъеме LAN так же "моргает" после записи нуля в DMATPDR, т.е. что-то через физику уходит.

В регистре DMASR, разницы с проявлением глюка - не вижу.

Биты TPS, NIS, ETS выставляются так же.

в MMCTGFCR (transmitted good frames counter register) после записи DMATPDR счет так же увеличивается ...

Честно говоря уже голову сломал, больше недели потратил - результат пока нулевой (

Думаю стек и драйвер от st не при делах.

Сверял все указатели непосредственно в регистре DMA, указатели на дескрипторы и их содержимое, на буфер Tx, все верно и не отличается от работы до появления этого глюка.

Думаю если создать свой буфер с дескриптором (да заполнить константами) и подцепить к DMA вместо буфера из стека, наверняка получится то же самое ...

Уже и Errata на STM32F429 пересмотрел, ничего похожего не нашел, что не удивительно.

e89oq2bq5i30.png

Edited by khomin

Share this post


Link to post
Share on other sites
Если ваеришак глючит - то это дерьмо а не снифер(сам его не юзал - хз)...

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

Share this post


Link to post
Share on other sites
....его не примет карточка и никто...

 

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

 

лично сам из опыта имею другие данные.

давно, в процессе запуска TCP/IP стека на 51 серии допускал и такие ошибки - сами пакеты ловились на ура Ethereal-ом.

Допускаю, что Вы имели опыт работы с другими конфигурациями топологии сети и(или) другими карточками.

Посему Ваше заявление о "ни кто" - не совсем истина.

 

PS

Если Вы тестировали в стандартном сегменте сети - то понятна причина :) Свитчи имеют маршрутизацию на втором

мак уровне(как правило), отгадайте как это решается задача и весь ли мусор они обязаны перенаправлять? :)

Edited by kolobok0

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this