STM32F767 Ethernet with DP83640


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?

Thank you very much,

Hello Rik,

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.

Hi Zoltan and all

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



Hi Zoltan,

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?

Kind regards,


Hello Rik,

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.

Hello Jerome,

Thank you for looking after this issue at ARM mbed. I can just support your proposal on having a configurable AUTONEGOTIATION using a json file.

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.

Well, I am not also expert in Ethernet things…
but it seems that default settings are for DP83848

Whereas default PHY for NUCLEO are LAN8742A :frowning:

Hi all

Please check

More parameters from
can be overwritten in your local mbed_app json file
and in particular the PHY register with the auto-negotiation result.


1 Like

this looks very good!

Thank you Jerome! I like it too.

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.