Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F107RB, проблема с ethernet.
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Atridies
Jun 29 2014, 21:41
Есть плата с микроконтроллером STM32F107RB. Поставил стек LwIP, обрезал лишнее, но запустить не получается. Не принимает входящие пакеты.
Данные на шине RMII - есть (CRS_DV, RXD0/1 - ведут себя вроде правильно). Настройка от порта LwIP - тоже вроде верная (уверен не на 100%, т.к. по битам регистров ETH - не гуру). Но какой бы пакет не передавал (ping или TCP) - статистика не увеличивается.

При этом - отправка пакета - вроде идёт правильно (статистика увеличивается, но в сниффере - пока не смотрел).

Насколько я понял по описанию - в случае отбраковки по какому-либо параметру на уровне MAC: все равно я должен иметь увеличивающуюся статистику.
Поставил loopback на MAC, дают передачу пакета - все равно статистика приема - не увеличивается.

Далее - значения всех регистров MAC и ETH_DMA:
CODE
www[0] = ETH->MACFFR; // 0000 0000
www[1] = ETH->MACFCR; // 0000 0000
www[2] = ETH->MACRWUFFR; // 0000 0000
www[3] = ETH->MACSR; // 0000 0000
www[4] = ETH->MACIMR; // 0000 0000
www[5] = ETH->MACA0HR; // 8000 0100 // 01.00.00.00.00.00.00 - MAC-адрес изделия.
// Сделаем 00.D0.59.12.32.5B.
www[6] = ETH->MACA0LR; // 0000 0000
www[7] = ETH->MACA1HR; // 0000 FFFF
www[8] = ETH->MACA1LR; // FFFF FFFF
www[9] = ETH->MACA2HR; // 0000 FFFF
www[10] = ETH->MACA2LR; // FFFF FFFF
www[11] = ETH->MACA3HR; // 0000 FFFF
www[12] = ETH->MACA3LR; // FFFF FFFF

www[13] = 0xA3FFFFA0;

www[14] = ETH->MMCCR; // 0000 0000
www[15] = ETH->MMCRIR; // 0000 0000 // Прерываний по статистике приема - не было.
www[16] = ETH->MMCTIR; // 0000 0000 // Прерываний по статистике передачи - не было.
www[17] = ETH->MMCRIMR; // 0000 0000 // Прерывания разрешены ?
www[18] = ETH->MMCTIMR; // 0000 0000 // Прерывания разрешены ?
www[19] = ETH->MMCTGFSCCR; // 0000 0000 // Количество переданных фреймов в HalfDuplex после одной коллизии.
www[20] = ETH->MMCTGFMSCCR; // 0000 0000 // Количество переданных фреймов в HalfDuplex после нескольких коллизий.
www[21] = ETH->MMCTGFCR; // 0000 0001 // !!!___ Количество удачно переданных фреймов.
www[22] = ETH->MMCRFCECR; // 0000 0000 // !!!___ Количество принятых фреймов с ошибкой CRC.
www[23] = ETH->MMCRFAECR; // 0000 0000 // !!!___ Количество притяных фреймов с ошибкой выравнивания.

www[24] = ETH->MMCRGUFCR; // 0000 0000 // !!!___ Кол-во хороших принятых фреймов с unicast.

www[25] = 0xA3FFFFA0;

www[26] = ETH->DMABMR; // 0002 0100
www[27] = ETH->DMATPDR; // 0000 0000
www[28] = ETH->DMARPDR; // 0000 0000
www[29] = ETH->DMARDLAR; // 2000 A930
www[30] = ETH->DMATDLAR; // 2000 A970
www[31] = ETH->DMASR; // 0066 0404
www[32] = ETH->DMAOMR; // 0000 2002
www[33] = ETH->DMAIER; // 0001 0040

www[34] = ETH->DMAMFBOCR; // 0000 0000
www[35] = ETH->DMACHTDR; // 2000 A980
www[36] = ETH->DMACHRDR; // 2000 A930
www[37] = ETH->DMACHTBAR; // 2000 C740
www[38] = ETH->DMACHRBAR; // 2000 A990



Где может быть отброс пакета ? Вообще как-то можно узнать: данные с RMII - поступают на вход MAC ?
Golikov A.
Jun 30 2014, 05:59
у LwIP есть встроенная диагностика, если включить ее на полную, вас завалит сообщениями что происходит, какие пакеты пришли и почему они не понравились. Обычно отладка идет в порт.
scifi
Jun 30 2014, 06:24
Цитата(Atridies @ Jun 30 2014, 01:41) *
Где может быть отброс пакета ? Вообще как-то можно узнать: данные с RMII - поступают на вход MAC ?

Там есть так называемый драйвер Ethernet MAC, в нём пакеты и принимаются. К примеру, у меня есть такой кусок кода:
Код
p = low_level_input();
if (p)
{
        ethernet_input(p, mynetif);
}

Если поставить точку останова на ethernet_input(), то в отладчике можно увидеть каждый принятый пакет.
Atridies
Jun 30 2014, 08:02
Цитата(scifi @ Jun 30 2014, 09:24) *
Там есть так называемый драйвер Ethernet MAC, в нём пакеты и принимаются. К примеру, у меня есть такой кусок кода:
Код
p = low_level_input();
if (p)
{
        ethernet_input(p, mynetif);
}

Если поставить точку останова на ethernet_input(), то в отладчике можно увидеть каждый принятый пакет.


Еще раз проверил - проблема не в драйвере MAC. Проблема в железе MAC.

Прием пакета идет следующим образом (вызовы функций):
ETH_IRQHandler -> LwIP_Pkt_Handle -> ethernetif_input -> low_level_input -> ETH_RxPkt_ChainMode.

Так вот: прерывания по ETH_IRQHandler - нету. Более того, регистры статистики в MAC (MACMMC) - не увеличиваются. Но данные на RMII - есть.
scifi
Jun 30 2014, 08:33
Цитата(Atridies @ Jun 30 2014, 12:02) *
Проблема в железе MAC.

Если точнее, то проблема в софте, как обычно.
Вы, случайно, не используете код для режима MII? Потому что в режиме RMII есть одна маленькая особенность.
bureau
Jun 30 2014, 08:43
Atridies
Вы re-map пинов верно провели? Откуда код брали? Сами с нуля подкручивали LwIP или брали пример с какой-то dev-board?
andrewlekar
Jun 30 2014, 09:48
У меня в своё время на прерывания драйвер тоже не заработал (LPC1768). Разбираться особо не стал и сделал на поллинге очереди DMA.
Atridies
Jun 30 2014, 10:50
Цитата(andrewlekar @ Jun 30 2014, 12:48) *
У меня в своё время на прерывания драйвер тоже не заработал (LPC1768). Разбираться особо не стал и сделал на поллинге очереди DMA.


1. Проверил еще раз ремап. Все нормально. У меня ремапится только SPI1, и он не попадает на ножки с RMII. Проверил настройку режимов пинов - тоже все нормально.

2. ПО взял из примера от ST-microelectronics: это был http-сервер с lwip. Лишнее выбросил и прикрутил к своей программе. Так что это - частично мое, а в основном - из примера.
Работу этого стека - я с devboard не проверял, ввиду отсутствия оной.

3. В этом примере была переключалка: MII/RMII. Она стоит на RMII. Судя по коду: dribble bit - не проверяется. Но даже если бы и проверялся - у MAC есть счетчик, который считает пакеты с ошибочным dribble bit (ETH_MMCRFAECR). А он у меня все время в нулях.

4. Странно, что прерывания не работают. Ну даже если так - статистика должна идти или нет? Я если честно уже запутался.

5. Еще никак не могу понять - где посмотреть: вообще в MAC приходят пакеты или нет? Пусть битые, чужие, пусть прерывания не так работают. Хоть какие-нибудь...
bureau
Jun 30 2014, 11:10
Была подобная проблема -- не приходили прерывания. Деталей не помню, но точно искал причину отсутствия прерываний.
На какой адрес настроена физика? (в железе и программе, значения совпадают?)
scifi
Jun 30 2014, 11:18
Цитата(bureau @ Jun 30 2014, 15:10) *
На какой адрес настроена физика? (в железе и программе, значения совпадают?)

Адресация есть на шине SMI. У интерфейса RMII никакой адресации нет. Так что совсем не в тему.
Кстати, возможны банальные ошибки в схемотехнике, если плату сами делали.
doom13
Jun 30 2014, 14:37
Цитата(scifi @ Jun 30 2014, 11:33) *
Вы, случайно, не используете код для режима MII? Потому что в режиме RMII есть одна маленькая особенность.

Если можно, тут по-подробнее, где искать и его название в либе.
Golikov A.
Jun 30 2014, 15:45
у меня глупый вопрос, а вы в МАК контроллер мак адрес передали? Может пакеты просто по этому параметру отфильтровываются?
Atridies
Jul 2 2014, 06:50
Проблема решилась. Дело было в неправильной настройке MAC. Не совпадала скорость и еще некоторые параметры.

Дело в том, что в примере был косячок: настройка PHY не производилась, если не подключен кабель. Я это махнул из программы, а заодно зацепил некоторые настройки.

Всем спасибо !

P.S. Теперь, Слава Богу, более-менее понимаю, как работает MAC.
fault-tolerant
Dec 22 2014, 15:07
Цитата(Atridies @ Jul 2 2014, 08:50) *
Проблема решилась. Дело было в неправильной настройке MAC. Не совпадала скорость и еще некоторые параметры.

Дело в том, что в примере был косячок: настройка PHY не производилась, если не подключен кабель. Я это махнул из программы, а заодно зацепил некоторые настройки.

Всем спасибо !

P.S. Теперь, Слава Богу, более-менее понимаю, как работает MAC.

Очень хотелось бы, если можно, чуть чуть поподробнее.

Мучаюсь с STM32F207, плата наша, разработана по примерам ST и Micrel, PHY - KSZ8051RNL. RMII в виду того, что много IO нужно было... И работает в принципе, только передавая файлы, как картинки по HTTP, или, на пример, в тестовой программе IPREF, вдруг виснет секунд на 15, тупо пережевывая склиентом один и тот же пакет. Клиент грит - ты проустила пакет номер такой-то, верни! А плата: на! А пакет не тот... А через 15 секунд примерно отпускает - но только на секунду, потом опять. Прилагаю картинку.

Уже чего только в параметрах стандартного ST-шного драйвера не менял, все регистры проверял, и MAC и PHY... Вроде "ETH_DMAMFBOCR" насчитывает непринятые пакеты, но настройки, с ним связанные, не помогают.

Может что у вас подберу по настройкам? Проблема не в программе, так как то же самое происходит в совершенно разных примерах, с LwIP, с NetX.

Спасибо!
Golikov A.
Dec 22 2014, 15:41
вроде пакетами это уже уровень выше мака и физики, сильно выше, это даже не IP а TCP уже...
точно не стэк виноват?
scifi
Dec 22 2014, 15:45
Duplex mismatch?
fault-tolerant
Dec 23 2014, 06:27
Цитата(Golikov A. @ Dec 22 2014, 17:41) *
вроде пакетами это уже уровень выше мака и физики, сильно выше, это даже не IP а TCP уже...
точно не стэк виноват?

Хотелось бы, но судя по всему - вряд ли. Во первых, этим драйвером многие пользуются. Во вторых, я брал совершенно разные демонстрационные/тестовые проги, общее одно - драйвер. Да и регистры вроде указывают на проблему на уровне MAC.
Сейчас пытаюсь проверять скорость и синхронизацию линий связи с регистрами PHY - MDC и MDIO... неправильные значения там приводят к ухудшению..
Golikov A.
Dec 23 2014, 06:33
а в драйверах проверили функцию посылки данных? Проследите всю цепочку посылки пакета (от формирования данных до выдачи в мак), иногда на нижнем уровне ошибки передачи заглушены 0 кодом без обработки. Потому ваш стэк думает что послал, а на самом деле что-то не пошло. По описанию больше похоже на программную ошибку....
fault-tolerant
Dec 23 2014, 06:50
Цитата(scifi @ Dec 22 2014, 17:45) *
Duplex mismatch?

Это я уже проходил :D
По скольку драйвер ST написан под PHY DP83848C, а у нас KSZ8051RNL, один регистр в нем не подходил - он считывал 0x10 для проверки рзультата autonegotiation, в то время как в KSZ8051RNL 0x10 отсутствует. Считывался ноль. По этому он заседал на Half/10. Правильный регистр 0x1E, да и биты в нем не те. Но это легко подстроилось, если кому надо.
В файле STM32f2x7_eth.c, вместо:
CODE
/* Configure the MAC with the Duplex Mode fixed by the auto-negotiation process */
if((RegValue & PHY_DUPLEX_STATUS) != (uint32_t)RESET)
{
/* Set Ethernet duplex mode to Full-duplex following the auto-negotiation */
ETH_InitStruct->ETH_Mode = ETH_Mode_FullDuplex;
}
else
{
/* Set Ethernet duplex mode to Half-duplex following the auto-negotiation */
ETH_InitStruct->ETH_Mode = ETH_Mode_HalfDuplex;
}

/* Configure the MAC with the speed fixed by the auto-negotiation process */
if(RegValue & PHY_SPEED_STATUS)
{
/* Set Ethernet speed to 10M following the auto-negotiation */
ETH_InitStruct->ETH_Speed = ETH_Speed_10M;
}
else
{
/* Set Ethernet speed to 100M following the auto-negotiation */
ETH_InitStruct->ETH_Speed = ETH_Speed_100M;
}

Можно вставить:
CODE
#define HALF_DUPLEX_10_BASE_T 1
#define HALF_DUPLEX_100_BASE_T 2
#define FULL_DUPLEX_10_BASE_T 5
#define FULL_DUPLEX_100_BASE_T 6

if((RegValue & FULL_DUPLEX_100_BASE_T) == FULL_DUPLEX_100_BASE_T)
{
ETH_InitStruct->ETH_Speed = ETH_Speed_100M;
ETH_InitStruct->ETH_Mode = ETH_Mode_FullDuplex;
}
else if((RegValue & FULL_DUPLEX_10_BASE_T) == FULL_DUPLEX_10_BASE_T)
{
ETH_InitStruct->ETH_Speed = ETH_Speed_10M;
ETH_InitStruct->ETH_Mode = ETH_Mode_FullDuplex;
}
else if((RegValue & HALF_DUPLEX_100_BASE_T) == HALF_DUPLEX_100_BASE_T)
{
ETH_InitStruct->ETH_Speed = ETH_Speed_100M;
ETH_InitStruct->ETH_Mode = ETH_Mode_HalfDuplex;
}
else if((RegValue & HALF_DUPLEX_10_BASE_T) == HALF_DUPLEX_10_BASE_T)
{
ETH_InitStruct->ETH_Speed = ETH_Speed_10M;
ETH_InitStruct->ETH_Mode = ETH_Mode_HalfDuplex;
}


Ну, и сам регистр - в stm32f2x7_eth_conf.h изменить на 0x1E:
Код
#define PHY_SR    ((uint16_t)0x1e)
fault-tolerant
Jan 19 2015, 08:18
Все еще никаких проблесков. Пытался изменить 100/10, Full/Half, проверял еше раз, что драйвер не вылетает ни на одном эксепшене... С задержкой в 10мс после каждого пакета ситуация с вебом, на пример, сносная, но все равно иногда на пару секунд зависает, ретрансмиты и т.д... Ну, а без этих задержек оно только ретрансмитами и занимается. И как поймать дебагером, когда именно оно глючит, не пойму..

Цитата(Golikov A. @ Dec 23 2014, 08:33) *
а в драйверах проверили функцию посылки данных? Проследите всю цепочку посылки пакета (от формирования данных до выдачи в мак), иногда на нижнем уровне ошибки передачи заглушены 0 кодом без обработки. Потому ваш стэк думает что послал, а на самом деле что-то не пошло. По описанию больше похоже на программную ошибку....

Что мог, проследил... Уже давно тыкаюсь. Когда слежу, судя по всему, что я вижу, посылает прекрасно. А вот как поймать сбой - до сих пор не пойму. в мыслях я уже тоже вернулся к взможности програмной ошибки как самой реальной, но не ловится крокодил.
Golikov A.
Jan 19 2015, 17:13
надо не за программой следить, надо текст почитать и найти все коды возвращаемых ошибок. И проанализировать, не стоит ли где на ошибку вернуть ошибки нет...
fault-tolerant
Jan 22 2015, 05:24
Так вот, взяв совершенно другой проэкт от ST с веб сервером на LwIP и без операционной системы, из моего используя только BSP, получаю тот же результат. То есть, проблема явно в настройках MAC или PHY, включая DMA. Прекрасная програмка tcping с опциями -t -h показывает, что чем больше пакетов передается (по типу http страницы), тем больше шансов "на застрять".
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.