[yanvasilij 0]

Доброго времени суток!

 

Вопрос возможно идиотский, я не силен в сетевых делах. Поднял на моей железке (stm32f429 + ksz8721) tcp-стек (FreeRTOS+TCP) и запустил обычный пинг с большой длинной (1460). Обнаружил, что иногда ответ на ping просто не приходит (происходит ошибка таймаута, а в wireshark не видно никакого ответа, даже битого). Это происходит редко скажем на 1000 запросов один таймаут. Долго мучался искал ошибку в драйвере. Когда отчаялся подумал, может ошибка не софтовая, тогда вывел значения регистра ETH_MMCRFCECR (Ethernet MMC received frames with CRC error counter register) и выяснил, что его значение постепенно увеличивается. Вот только таймаутов больше, чем значение в этом регистре (например этот счетчик натикал 131, а таймаутов 160). Но этот счетчик стабильно увеличивается и, если это можно так назвать, "коррелирует" с количеством таймаутов. Сейчас моя железка соединена с ноутбуком "напрямую". На ноуте в wireshark'е я не вижу входящих фреймов с битым crc, но если я правильно понимаю это отрабатывается уровнем ниже, поэтому я и не увижу ничего.

 

Правильно ли я понимаю, что увеличивающийся ETH_MMCRFCECR сигнализирует о входящий фреймах с битым CRC, что косвенно указывает на аппаратный "недуг"?

Изменено 22 ноября, 2022 пользователем haker_fox
Уточнил название темы, добавил теги, переместил в нужный раздел.

[scifi 1]

Обычно пишут, что кварц должен быть с точностью 50ppm. Интересно, если отклонение больше, как это будет проявляться? Может быть, будут биться длинные кадры?

Ещё вроде бы у STM32F4 встроенный PLL имеет слишком большой джиттер для тактирования Ethernet PHY, тоже имеет смысл проверить.

[yanvasilij 0]

Кварц достаточно точный, марку смогу назвать только завтра, точнее это даже не кварц а мемс-генератор на 50 МГц (у нас RMII). А по поводу тактирования физики: в случае с внешним кварцем разве есть тактирование от процессора? Или я чего то не понял?

[scifi 1]

Кварц достаточно точный, марку смогу назвать только завтра, точнее это даже не кварц а мемс-генератор на 50 МГц (у нас RMII).

Кстати, недавно по ошибке впаял MEMS вместо TCXO. Были чудеса. Но это был внешний PLL в качестве генератора тона. Надеюсь, MEMS годится для Ethernet PHY, но я бы погуглил.

 

А по поводу тактирования физики: в случае с внешним кварцем разве есть тактирование от процессора? Или я чего то не понял?

Можно тактировать МК от кварца и использовать его PLL для создания тактовой для Ethernet PHY. При таком варианте возможны проблемы.

[jcxz 183]

Можно тактировать МК от кварца и использовать его PLL для создания тактовой для Ethernet PHY. При таком варианте возможны проблемы.

Вероятно можно подобрать коэффициенты умножения PLL такие, чтобы джиттер был минимальным. Может даже уложился в требования по допускам Ethernet? В установившемся режиме PLL конечно.

 

Но лучше сделать наоборот: не Ethernet-физику тактировать от МК, а МК тактировать от Phy.

Мы так делали в одном устройстве: Генератор подключали к физике, а с неё брали 25МГц и заводили на вход тактирования МК. Так что физика тактировалась без PLL с минимальным джиттером.

[yanvasilij 0]

Наш кварц - SiT8103AI-23-33E-50.00000. Физика тактируется от кварца

[jcxz 183]

Наш кварц - SiT8103AI-23-33E-50.00000. Физика тактируется от кварца

А у вашей физики нету выхода тактовой частоты (или делённой на 2)? Его можно было бы завести на вход тактирования МК.

Ну или применить вместо кварца генератор и завести параллельно (если входная частота МК позволяет).

[Сергей Борщ 119]

А у вашей физики нету выхода тактовой частоты (или делённой на 2)? Его можно было бы завести на вход тактирования МК.

А смысл тактировать ядро этой частотй? На тактирование MAC эта частота заводится - в виде 50 МГц на вход RMII_REF_CLK. Тактированию ядра эта частота никак не мешает, но и помочь не может - тактирование ядра тут роли не играет.

[jcxz 183]

А смысл тактировать ядро этой частотй? На тактирование MAC эта частота заводится - в виде 50 МГц на вход RMII_REF_CLK. Тактированию ядра эта частота никак не мешает, но и помочь не может - тактирование ядра тут роли не играет.

Мы так делали для удешевления. Процессору всё равно нужен был хороший генератор с большой стабильностью (по ТЗ внутренний RTC должен был иметь низкий уход за сутки).

Так что - почему бы и не затактировать тогда и физику Ethernet от хорошего генератора, раз он всё равно есть в системе, чем ставить отдельный дешёвый кварц с большой погрешностью?

А два хороших ставить - дорого.

[PIC16F876A 0]

Обычно в таких связках максимальная длина IP пакета по умолчанию 570 с чем то байт. Вы ничего не меняли в этих настройках ?

[yanvasilij 0]

Обычно в таких связках максимальная длина IP пакета по умолчанию 570 с чем то байт. Вы ничего не меняли в этих настройках ?

 

Я настроил максимальную длинну на 1460, я имею ввиду настройки DMA дескрипторов. Думаете в этом дело? Завтра попробую изменить.

 

И еще, в попытке прояснить ситуацию сделал следующее на машине с linux запустил интенсивный пинг (моя плата соединена с ней прямым кабелем напрямую) и при помощи ПО ethtool (под win я не нашел ничего подобного) заглянул в статистику. Выяснил, что linux-машина тоже ловит пакеты с битым CRC. После этого взял другую борду (stm32f429 discovery) с другой физикой, поднял на ней простой проект, и запинговал аналогичным образом. Пакетов с битым CRC linux в этом случае не обнаружил. Очень похоже на что-то аппаратное, но не уверен.