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

Вопрос возможно идиотский, я не силен в сетевых делах. Поднял на моей железке (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, что косвенно указывает на аппаратный "недуг"?

Обычно пишут, что кварц должен быть с точностью 50ppm. Интересно, если отклонение больше, как это будет проявляться? Может быть, будут биться длинные кадры?
Ещё вроде бы у STM32F4 встроенный PLL имеет слишком большой джиттер для тактирования Ethernet PHY, тоже имеет смысл проверить.

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

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


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

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

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

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

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

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

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

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

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

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