I was testing an ethernet based project PCB that uses LAN8742a xip (lan xip seller link) and a stm32f207zg microcontroller (mcu seller link). We are having some issues when we increase the stress level. So I was debugging the application (it's a server) whereas I was waiting for the moment in which communication gets lost (some hours later).
Application is implemented using HAL layer drivers, LwIP stack and no RTOS. Mac was configured in 100MB speed mode and full-duplex mode.
At the arrived moment I watched status registers values and the status Rx descriptor register value too. What a surprise that I could see that there was a half-duplex mode flag. So I checked MAC configuration register value, where I see the DM (duplex mode) was reset. So I also checked this one once again when MAC controller was initialized. It was also reset. I also see that during HAL_Init function, this level layer driver ask to the LAN xip for the result of the autonegotiation.
Here, in stm32f2xx_hal_eth.c file:
HAL_StatusTypeDef HAL_ETH_Init(ETH_HandleTypeDef *heth)
{
...
/* Read the result of the auto-negotiation */
if((HAL_ETH_ReadPHYRegister(heth, PHY_SR, &phyreg)) != HAL_OK)
...
}
This microcontroller driver reads a half-duplex mode from LAN xip registers. Meaning that after autonegotiation between LAN and the remote host the result is that full-duplex is not achieved by this link.
- If the remote host is a PC how can it be possible that the link only supports half-duplex mode?
- Which can be the limitation or problem for full-duplex identify?
- Any suggestions in order to solve and to find the problem source?
