Ksz8041 не отправляет через Хаб, а напрямую работает Опции

[khomin]

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

[Alex11]

Ниже Wireshark'а из PC не посмотрите. Карточка все битые пакеты выкидывает безоговорочно.

[kolobok0]

Ниже Wireshark'а из PC не посмотрите. Карточка все битые пакеты выкидывает безоговорочно.

о как...

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

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

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

всегда юзал Ethereal. Он точно показывает всё что послано в сеть. Т.е. не опознанные, битые, ошибочные с точки зрения формата
и с точки зрения протокола.
Если ваеришак глючит - то это дерьмо а не снифер(сам его не юзал - хз)... Но подозреваю что всё-таки проблема в передатчике.
Попробуйте в обработчике передатчика подсчитывать реально поставленных на передачу в железо пакеты. И на более высоком уровне
- переданных на саму передачу. Или по другому - как Вы контролируете что передача происходит? Проверяли ли отладчиком
обработку прерывания передатчика(окончания передачи ПДП)? Там всё корректно? Как Вы отрабатываете сборку DMA отработанных
сегментов? Там всё корректно(возвращается ли память обратно в свободный пул, корректна ли обработка нехватка памяти и нет ли
зависимости обработчика прерывания от тяжёлых функций)? В своё время меня не устроил обработчик по умолчанию - дюже тяжёл был.
Пришлось доводить до ума.

[khomin]

как Вы контролируете что передача происходит? Проверяли ли отладчиком
обработку прерывания передатчика(окончания передачи ПДП)? Там всё корректно? Как Вы отрабатываете сборку 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 пересмотрел, ничего похожего не нашел, что не удивительно.


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