Всем доброго времени суток.
Уже несколько дней старательно долблюсь лбом в одну и ту же точку мануала - в часть, посвящённую работе с Ethernet.
Есть кристалл STM32F107VCT6, код ревизии - Z, если кому интересно. К кристаллу подключен внешним PHY контроллер TLK105R (особой сути не имеет). Приём/Передача фреймов со случайными данными (не IP, а именно "шума") проходит отлично, они видятся в Wireshark'е. Приём данных от ПК так же работает. В качестве драйвера используется STM32 HAL. Точнее, его участки, отвечающие за инициализацию переферии (да и то далеко не все).
Суть в чём. ICMP проходит, ARP носится в обе стороны при необходимости, НО: при попытке отправить UDP пакет со стороны контроллера, в сеть он не вылетает. При этом, контроллер вежливо интересуется, есть ли в сети машина с IP адресом ПК, получает обратно ARP ответ, обрабатывает его, собирает UDP пакет до конца и... НИЧЕГО. Пакет не уходит. Повторная отправка и десяток отправок ничего не меняют.
Но теперь если изменить хоть один бит в ARP таблице, либо в буфере отправки непосредственно перед командой начала передачи - пакет чудесным образом вылетит в сеть. Пробовал отключать/включать автодобавление CRC в пакет - не помогает. Отключал вообще работу с CRC заголовками на уровне MAC контроллера - так же безрезультатно. Зато, если изменить данные в таблице ARP и отправить пакет обычным образом (пусть даже на соседний мак-адрес), пакет полетит. После можно вернуть бит обратно (в ARP) и пакеты начнут ходить как положено.

Кто-нибудь сталкивался с подобными замашками?
И, да, если сменить тип пакета с IP на нули - пакет уходит. Сменить IP назначения в пакете - уходит (по маку). Сменить мак (любой) - уходит. А правильно собраный пакет требует эдакого шаманства.

Опять же, описание состояния контроллера:
Кварц 8МГц. Системная частота 50МГц. Тактирование PHY - через MCO пин 25МГц.
Питание в пределах допуска - 3.0V.
Ёмкости в обвязке в порядке.

Внутрисхемной отладки нет совсем что ли? Поставить точку останова на отправке, посмотреть, что куда идёт или не идёт.

Как раз отладка ничем не может помочь. Проблема где-то либо в пакете, либо в самом MAC модуле кристалла.
Потому что уже все шаги проверялись от и до. Вплоть до бумажки и вычислений.
Если даже просто забить в буфер готовый пакет, собрав его как положено, и вызвать HAL_ETH_TransmittFrame() - пакет уйдёт, будучи слегка побитым, но не уйдёт, будучи собран правильно.

Опишу, как всё устроено чуть подробнее, раз уж возникают подобные вопросы.
Буферы приёма и передачи разнесены. Приёмных 4 (но можно использовать только пару, не суть критично), буфер отправки один.
Приём пакетов происходит аппаратно, обработчик вызывается по событию (флагу), а не в прерывании, так что конфликтов быть не может.
Пакет формируется процедурно, без лишних копирований. При этом, все "служебные" пакеты собираются аналогичным образом - пакет копируется в буфер передачи полностью, затем над ним происходят манипуляции для ответа (в частности ARP и ICMP). Затем вызывается процедура отправвки (менее 10 строк кода, где записываются поля дескриптора передачи и проставляется бит "ETH_DMA_OWN"). Далее пакет отправляется аппаратурой.
Где именно кроется проблема - не могу понять, поскольку все отправленные пакеты увеличивают регистр-счётчик "Пакетов передано успешно". Но "проблемные" фреймы просто не уходят.
Если поставить бит LoopBack в соответствующем регистре ETH_MAC, то пакеты, которые реально отправляются будут попадать в приёмные буферы. А проблемные - нет.

Чтож. Печально находить грабли в коде. Ещё печальнее искать их там, когда их нет.
Оказалось, что пакеты на самом деле уходят. Просто сетевая карта не переключалась в прозрачный режим, а дарйвер WireShark не отлавливал пакеты, которые сбрасывал по каким-то одному ему известным причинам фаервол.
Вот так было угроблено несколько дней на отладку проблемы, которой просто не было на самом деле.
=(
Обидно.