[U_K 0]

1 час назад, aaarrr сказал:

А в момент выполнения

тактирование точно есть? А то мало ли, вдруг позже появляется.

как раз перед этим циклом проверяю

[aaarrr 63]

Странно. А тактирование микроконтроллера как настроено?

[U_K 0]

Тактирование настроено на внешний кварц 25МГц, отдельный кварц, второй на плате(после кварца для PHY). В коде установлено HSE value = 25000000, регистры с тактированием STM уже проверял. У TX_CLK и RX_CLK амплитуда до 2.6В, может нужно хотя бы 3В?(Хотя возможно, амплитуда уменьшается из-за щупов для такой частоты)

Изменено 18 июня, 2021 пользователем U_K

[aaarrr 63]

6 minutes ago, U_K said:

Тактирование настроено на внешний кварц 25МГц

А PLL? Не получается AHB < 25MHz?

 

 

 

8 minutes ago, U_K said:

У TX_CLK и RX_CLK амплитуда до 2.6В, может нужно хотя бы 3В?

Скорее всего, артефакт измерения.

[U_K 0]

18.06.2021 в 18:22, aaarrr сказал:

А PLL? Не получается AHB < 25MHz?

Проверил перед циклом, все нормально, AHB Prescaler=1, после него 168МГц. Перед ним 168 МГц идет на Ethernet PTP clock, но однако из регистра RCC->AHB1ENR, Ethernet PTP clock disabled. Если что вот регистры:

RCC->CR 03 03 87 83
HSEON=1(HSE clock enable)
HSERDY=1(HSE clock ready flag)

HSION=1(Internal high-speed clock enable) - если у нас внешнее тактирование, HSI вроде должен быть выключен?

HSIRDY=1

PLLRDY=1(Main PLL (PLL) clock ready flag)
PLLON=1( Main PLL (PLL) enable)

 

RCC->PLLCFGR 04 40 54 19
PLLQ=4 PLLP=2 PLLN=336 PLLM=25
f(VCO)=25*336/25=336МГц
f(PLL general clock output)=336/2=168МГц

 

RCC->CFGR 00 00 94 0A
RTCPRE 00000(no clock)
PPRE2(APB2)=100(divided by 2)
PPRE1(APB1)=101(divided by 4)
HPRE(AHB)=0000(system clock not divided)
SWS=10(PLL used as the system clock)
SW=10(PLL selected as system clock)

 

 

Изменено 21 июня, 2021 пользователем U_K

[U_K 0]

В while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET) заккомментировал "return HAL_TIMEOUT" и добавил break. Бит SR в DMABMR стал сбрасываться - источник https://www.programmersought.com/article/52516336171/
Добрался до чтения регистра PHY_BSR (HAL_ETH_ReadPHYRegister(heth, PHY_BSR, &phyreg)) - теперь зависает в цикле while (((phyreg & PHY_LINKED_STATUS) != PHY_LINKED_STATUS))
Регистры у PHY читаются, все нормально. Проблема теперь в том, что бит LINK STATUS в PHY BSR не устанавливается. 

Изменено 23 июня, 2021 пользователем U_K

[aaarrr 63]

9 minutes ago, U_K said:

Проблема теперь в том, что бит LINK STATUS в PHY BSR не устанавливается.

PHY сконфигурирован на auto negotiation? Что удаленная сторона видит?

 

Можно еще локальную петлю кабелем попробовать, если на дальнем конце линка тоже нет.

[U_K 0]

22 часа назад, aaarrr сказал:

PHY сконфигурирован на auto negotiation? Что удаленная сторона видит?

Можно еще локальную петлю кабелем попробовать, если на дальнем конце линка тоже нет.

Из регистра PHY_BMCR (39 00) - Autonegation Enable, PHY-BMSR (78 49). На ПК, в Wireshark все то же самое, как и раньше(ПК спрашивает "Who has 192.168.1.1? Tell 192.168.1.192", но никто не отвечает). Светодиоды на разъеме Ethernet на плате - один горит постоянно, другой мигает периодически(когда ПК шлет данные). Локальная петля кабелем - в смысле закоротить TX и RX на кабеле, из МК что-то отправить через PHY и обратно через PHY принять? 

[aaarrr 63]

Судя по всему, линк на месте.

[U_K 0]

21 час назад, aaarrr сказал:

Судя по всему, линк на месте.

Наконец-то выяснил источник проблемы. При чтении регистра PHY_BMCR выдавалось 0x3900, так из этого значения получается, что PHY находится в POWER-DOWN режиме. Еще раз посмотрел на схему - пин PB14(MII_INT) у STM соединен с пином PWR_DN/INT у DP83848. Так вот, нужно было подтянуть в этом случае MII_INT к питанию. Cделал это в инициализации GPIO. Инициализация в HAL_ETH_Init теперь выдает HAL_OK (и бит SR в DMAMBR сбрасывается когда нужно, и бит link status в регистре BMSR у DP83848 устанавливается). И соотвественно ping есть. Вот так, очередной раз у меня из-за такой мелочи, не работало. Кто помогал - большое спасибо! 

[aaarrr 63]

Поздравляю! Захватывающая получилась история.

[Сергей Борщ 119]

Самое главное и приятное во всей этой истории, что вы нашли и устранили причину, а не побороли симптомы, как это бывает в большинстве случаев, к сожалению.

[danone78 0]

запись в phy регистры проверяли по MDC MDIO? 

[Grootoportunities 0]

В 25.06.2021 в 14:43, U_K сказал:

Наконец-то выяснил источник проблемы. При чтении регистра PHY_BMCR выдавалось 0x3900, так из этого значения получается, что PHY находится в POWER-DOWN режиме. Еще раз посмотрел на схему - пин PB14(MII_INT) у STM соединен с пином PWR_DN/INT у DP83848. Так вот, нужно было подтянуть в этом случае MII_INT к питанию. Cделал это в инициализации GPIO. Инициализация в HAL_ETH_Init теперь выдает HAL_OK (и бит SR в DMAMBR сбрасывается когда нужно, и бит link status в регистре BMSR у DP83848 устанавливается). И соотвественно ping есть. Вот так, очередной раз у меня из-за такой мелочи, не работало. Кто помогал - большое спасибо! 

Подскажите, как именно по схеме вы нашли что у вас этот пин соеденен с пином, и как именно его инициализировали в GPIO? Пытаюсь связать DP83848 с STM32F429I-DISC1, и не совсем понимаю по своей схеме как вы это определили. Имею такую же проблему, но получилось закомментировать return в цикле из сообщений выше, но тогда эхо в вайршарке не работает.

[U_K 0]

В 28.06.2023 в 16:23, Grootoportunities сказал:

Подскажите, как именно по схеме вы нашли что у вас этот пин соеденен с пином, и как именно его инициализировали в GPIO? Пытаюсь связать DP83848 с STM32F429I-DISC1, и не совсем понимаю по своей схеме как вы это определили. Имею такую же проблему, но получилось закомментировать return в цикле из сообщений выше, но тогда эхо в вайршарке не работает.

На фрагменте схемы можно посмотреть как соединен MII_INT с PWR/DN INT. В GPIO подтянул MII_INT к питанию  -  HAL_GPIO_WritePin(MII_INT_GPIO_Port, MII_INT_Pin, GPIO_PIN_SET);