EMACInterface::connect() always succeeds with an incorrect PHY address

[timovanasten]

Description of defect

We use a custom board based on the NUCLEOF767ZI, but we've used another PHY transceiver than the one on the NUCLEO for the Ethernet connectivity. We had to change the PHY address for this but noticed that EMACInterface::connect() always returns 0 (i.e. success) when using an incorrect PHY address. I think the desired response should be an error in this case. We suspect that this is caused by the fact that when PHY address is configured incorrectly, the HAL_ETH_ReadPHYRegister(ETH_HandleTypeDef *heth, uint16_t PHYReg, uint32_t *RegValue) in stm32f7xx_hal_eth.c seems to always return 0b1111111111111111 if the PHY is incorrect.

Target(s) affected by this defect ?

NUCLEOF7xx, Custom targets based on STM32F7xx targets

Toolchain(s) (name and version) displaying this defect ?

gcc-arm-none-eabi 9.2.1

What version of Mbed-os are you using (tag or sha) ?

5.15

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli 1.10.2

How is this defect reproduced ?

For the NUCLEOF767ZI, change the ETH_ARCH_PHY_ADDRESS defined stm32xx_emac.cpp from (0x00) to (0x01). Then call NetworkInterface::get_default_instance().connect(). This will always return 0.

[0xc0170]

cc @ARMmbed/mbed-os-ipcore

[michalpasztamobica]

Hi @timovanasten .
Please check #12405. Seems like we may need to add another "target_override" for NUCLEOF767ZI?

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2542

[timovanasten]

@michalpasztamobica That would definitely be a nice option to have. Right now we need to dig into the drivers ourselves which seems a bit hacky. It doesn't solve the issue about the return value of the connect() function not representing the actual situation if the PHY address is wrongly configured though.

[michalpasztamobica]

You're right. But to check the return values of ST driver functions, we may need to ask someone from ST. @LMESTM , can you give us a hand with this? @0xc0170 , I can see team-st-mcd tag, but I am not sure what MCD stands for, so I don't dare to use it, so that I don't bother some innocent people...

[jeromecoutant]

Hi
I also think #12405 is solving this issue ?
You then just need to add in your mbed_app json file something like
"stm32-emac.eth-phyaddr": 1

[jeromecoutant]

@michalpasztamobica
Yes you can use @ARMmbed/team-st-mcd alias :-)
MCD is the ST entity in charge of STM32 support

[michalpasztamobica]

@jeromecoutant , I think @timovanasten still has a point, that in case of invalid PHY_ADDR the value returned from HAL_ETH_ReadPHYRegister should be some error code, rather than b'111111...
The function returns HAL_StatusTypeDef, perhaps it would be good to detect the issue and return HAL_ERROR = 0x01U?

[jeromecoutant]

Something like this ?
jeromecoutant@f6059c1

[timovanasten]

@jeromecoutant Just quickly checked out your commit, but it seems like the connect() method still returns 0 while using the wrong PHY address

[timovanasten]

@jeromecoutant Just checked that HAL_ETH_ReadPHYRegister returns HAL_OK with a wrong PHY address.

[jeromecoutant]

@timovanasten
Could you try jeromecoutant@8abf2a7 ?
Thx