I’m using the DP83640 PHY transceiver to communicate with the STM32F767 over Ethernet. This one is different from the one on the Nucleo version of this chip, which is the LAN8742A. I connected every pin of the PHY transceiver as described in the datasheet and used the same pins as on the Nucleo version of this chip (both are using the RMII interface). Also, the registers that are configured in the mbed-os software are the same for both PHY transceivers. The only difference is the PHY address of both PHY transceivers (1 for the DP83640 and 0 for the LAN8742A). I solved this by changing ETH_ARCH_PHY_ADDRESS in stm32xx_emac.cpp in the library files of mbed-os.
As soon as I run my code on the Nucleo it works perfectly, while it gives an connection error (-3004) when I run the code using the DP83640 as PHY transceiver. Can someone help me with this issue?
I had similar issue when trying to use LAN8720 with STM32F407VE. But disabling AutoNegotiation in stm32xx_emac.cpp fixed the problem. Maybe it will work also in your case.
Maybe you should push a patch in mbed-os?
I was thinking about a configurable define in features/netsocket/emac-drivers/TARGET_STM/mbed_lib.json
with default value set to ETH_AUTONEGOTIATION_ENABLE,
then you can overwrite it in your mbed_app json files
Thank you for your quick reply. I have tried to disable auto-negotiation but it didn’t solve the problem. Moreover, the link is only established when the speed is 10 Mbit/s and half-duplex mode is selected. Thereafter, the socket gives an error indicating an connection error (error code -3004). Could this mean that a part of the PHY transceiver is broken or do you think something else is wrong with the PHY transceiver?
I’m sorry, I’m not an expert in this field. I just tried to share my experience. Actually, it was Johannes who figured that out. Maybe he can give you some additional hints.
how about the registers in both PHYs? The problem with LAN8720 was that the init in HAL used extended registers that are not compatible among different PHY chips.
For the F7, there is an own Mbed implementation, but I guess it is written for the LAN8742A registers. You need to check which registers are used and if they are compatible with DP83640.
I’m also no expert for the PHY codes, it looks like there is a basic set of registers which are equal, but I don’t know if this has been updated with newer Ethernet standards.
I have pulled Jeromes branch and it is working. It fixes also the problem with autonegotiation with LAN8720. The main reason was also the wrong PHY address, for these Waveshare modules (or clones), the address is hardwired to 1. So the code was not talking to the PHY and there was no check that a response does not contain valid data. With autoneg it worked only accidentaly because of default init and an ‘interface is up’ was detected in the invalid response bits (0xffff).
I have not yet tested it with setting the correct PHY_SR and mask setting, but I’m sure it will work.
Another suggestion: a PHY ID can be read. This could be read out and provided in an API or printed in the debug/trace log. When this ID is invalid, a warning can be issued to find a wrong PHY address easier.
