Не работает Ethernet на stm32f107, Не могу заставить контроллер принимать ethernet-пакеты Опции

[GreyM]

Использую TE-stm32f107. Пытался запустить тестовый пример из IAR'а - WebServer_Demo_uIP. Контроллер на все попытки общения по сети не отзывается. Тогда я нашел на сайте терры аналогичный пример (правда под gcc), взял из него инициализацию пинов (подумал, вдруг различается). Результата нет. Тогда я убрал инициализацию веб-сервера и попробовал на уровне MAC передавать сообщения от контроллера на хост и обратно. Соединил проводом - пробую. Контроллер напрямую отправляет пакеты, хост ловит. Обратно - пакеты отправляются, контроллер - ноль эмоций. Предположил, что может не вызываться обработка приходящих сообщений (хотя до этого брейки ставил везде где можно) - попробовал настроить прерывания по Ethernet - не реагируют ни на прием, ни на отправку. При этом другие прерывания работают.
Пока больше идей нет.
В чем может быть дело? Помогите, пожалуйста!

Сообщение отредактировал GreyM - Oct 5 2011, 14:26

[Ден]

С Ethernet не работал, но могу дать завалявшиеся у меня библиотеки, как раз для 107 камня под IAR, надеюсь поможет.
STM32F107_LwIP_IAP_V1.0.0
STM32F107_ETH_LwIP_V1.0.0

[GreyM]

Попробовал. Один пример уходит в хард фолт (пока что не понял где), второй запускается, но пинг не идет.
Начинаю сомневаться в работоспособности эвернета на плате. Может быть посоветуете, как вообще можно проверить работоспособность платы на прием сообщений?

Сообщение отредактировал GreyM - Oct 10 2011, 08:51

[scifi]

Попробовал. Один пример уходит в хард фолт (пока что не понял где), второй запускается, но пинг не идет.
Начинаю сомневаться в работоспособности эвернета на плате. Может быть посоветуете, как вообще можно проверить работоспособность платы на прием сообщений?

Можно осциллографом посмотреть на физический уровень: при отсутствии трафика должны идти периодические импульсы (это на 10 мбит/с, на 100, кажется, сложнее). По ним можно проверить на обрывы и КЗ.
Ну а в программе ищем, где ловятся принятые пакеты и ставим точку останова под отладчиком. Далее - собственно отладка ethernet драйвера, TCP/IP стека и т.д.

[GreyM]

Ну а в программе ищем, где ловятся принятые пакеты и ставим точку останова под отладчиком. Далее - собственно отладка ethernet драйвера, TCP/IP стека и т.д.

В программе поочередно ставил точки останова где только можно - ни одна ни разу не сработала. Поэтому и есть подозрение на нерабочий PHY.

Остальное буду пробовать

[EugenyAM]

В программе поочередно ставил точки останова где только можно - ни одна ни разу не сработала. Поэтому и есть подозрение на нерабочий PHY.

Разные PHY отличаются расширенным набором регистров. Тот пример, который я запустил, был написан под DP83848, она стоит на платах STM3210C-EVAL, на платах MCB2300 (LPC) от KEIL, StarterKit использует KS8721BL, я использовал ST802RT1. Если посмотреть на наборы регистров различных PHY, видно, что совпадают только первые 9 регистров. Дальше каждый производитель придумывает по-своему.

Инициализация PHY в примере находится в Stm32eth.c, функция

Код

uint32_t ETH_Init(ETH_InitTypeDef* ETH_InitStruct, uint16_t PHYAddress)

Обращение к регистрам делается из нее вызовами функций

Код

uint16_t ETH_ReadPHYRegister(uint16_t PHYAddress, uint16_t PHYReg)
uint32_t ETH_WritePHYRegister(uint16_t PHYAddress, uint16_t PHYReg, uint16_t PHYValue)

Если посмотреть, к каким регистрам PHY идет обращение, мы увидим PHY_BCR, PHY_BSR и PHY_SR
их номера определены в Stm32_eth.h, в комментариях написано, что определения для DP83848.
BCR и BSR для всех PHY равны 0 и 1 соответственно, а вот SR (из которого мы читаем фактические параметры соединения скорость/дуплекс после автодетекта) для DP83848 равен 0x10, для ST802RT1 уже 0x11, а если посмотреть даташит на KS8721, окажется, что нужная нам информация находится в регистре 0x1F. Естественно, что у каждого PHY используются свои комбинации битов для индикации состояния. Вот эти моменты и нужно в первую очередь исправить в процедуре инициализации под конкретную модель PHY.
Также если в ките предусмотрены джамперы для переключения MII/RMII и выбора адреса PHY, нужно проверить, правильно ли они выставлены. В примере используется адрес PHY 0x01.

Замечено, что в широко известных примерах применения Ethernet-контроллера для STM и LPC работе с PHY уделяется мало внимания. Например процедура автоопределения проводится только в момент инициализации, при этом, если кабель не подключен, мы выйдем из инита по ошибке, которую далее никто не ловит и программа продолжает работать, как будто все прошло нормально. Если после этого воткнуть кабель, не факт, что связь будет установлена, хотя индикатор Link загорится. Постоянно отслеживать Link Status в регистре PHY не есть красиво (но в примерах не делается даже это). Разработчики китов часто игнорируют сигналы прерывания от PHY, а ведь ими можно воспользоваться для отслеживания ситуации с кабелем. Можно настроить PHY на выработку прерываний при подключении/отключении кабеля и при наступлении данного события проводить процедуру автоопределения заново, ведь не только в PHY производится выбор скорости и дуплекса, но и в регистрах MAC тоже должны быть установлены соответствующие биты.

В общем, если Вы разрабатываете реальное устройство для реальных сетей, не бойтесь изучать даташиты. В них можно найти практически все ответы на вопросы.
--------

Что и где можно посмотреть осциллографом. (считаем, что у нас режим RMII, скорость 100Мбит/с).
Обозначения выводов даны по STM32 Reference Manual (далее REF)

MCO -> ETH_RMII_REF_CLK - частота 50 MHz

ETH_MDC - при обращениях к регистру PHY пачка импульсов ~64шт. с частотой 2,5 МГц
ETH_MDIO - на втором канале осциллографа смотрим обмен данными с PHY после первых 32 импульсов на ETH_MDC. Здесь можно увидеть, отвечает ли нам PHY по каналу управления (SMI).
Описание формата данных REF стр 918, figure 327-328.

ETH_RMII_CRS_DV - Импульс лог.1 длительностью от 6 мкс. В это время вторым каналом наблюдаем принимаемые от PHY пакеты данных на ETH_RMII_RXD0, ETH_RMII_RXD1 (частота 25МГц). Если этого импульса нет - PHY не ловит входные пакеты (естественно хост должен что-то передавать, например Ping). Если импульсы есть - проверяем соответствие настроек MAC и PHY (скорость/дуплекс).

ETH_RMII_TX_EN - Импульс лог.1 длительностью от 6 мкс. В это время вторым каналом наблюдаем передаваемые от МК пакеты данных на ETH_RMII_TXD0, ETH_RMII_TXD1 (Частота 25МГц) (МК должен быть настроен на передачу пакетов или отвечать на принимаемые).
---------

PS А проблемы, описанной в данной теме в Вашем ките случайно нет?
http://electronix.ru/forum/index.php?showt...amp;hl=ethernet

Сообщение отредактировал EugenyAM - Oct 14 2011, 04:23