STM32 ETH: Does not work with CLI 2

[boraozgen]

Description of defect

When built with CLI 2, the NUCLEO_F429ZI Ethernet interface does not work. It works with CLI 1. I wonder what kind of a difference the build system could make on this..?

Here is the output of the sockets example.

Starting socket demo

Connecting to the network...
[INFO][STE1]: power_up: PHY Addr 0 AutoNeg 1
[DBG ][STE1]: MAC Addr 00:80:e1:25:00:21
[INFO][STE1]: ETH buffers : 4 Rx 4 Tx
[ERR ][STE1]: HAL_ETH_Init issue
[INFO][STE1]: PHY ID 0
[INFO][STE1]: low_level_init_successful
Error! _net->connect() returned: -3004

Target(s) affected by this defect ?

NUCLEO_F429ZI

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

GNU Arm Embedded Toolchain 9-2020-q2-update

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

mbed-os-6.9.0

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

mbed-tools 7.8.0

How is this defect reproduced ?

Build the sockets example for NUCLEO_F429ZI & run.

[boraozgen]

@jeromecoutant could you test this please?

[jeromecoutant]

Hi
I could not even compile...

$ mbedtools compile -m NUCLEO_F429ZI -t ARM -f

ninja: fatal: CreateProcess: The parameter is incorrect.
 (is the command line too long?)
ERROR: CMake invocation failed!

[boraozgen]

Never saw this but looks like a path size issue... maybe move to a shorter directory?

[0xc0170]

$ mbedtools compile -m NUCLEO_F429ZI -t ARM -f

Ninja has a bug with ARMCLang - response file paths not escaped. Can you test Gcc (also reported with Gcc Arm)?

[jeromecoutant]

OK, with GCC, I confirm that application built with CLI1 is OK,
and failed with CLI2

[boraozgen]

Thanks. Any ideas about the cause?

[jeromecoutant]

I suppose some CMakeLists.txt file(s) are wrong...

[jeromecoutant]

stm32f4_eth_init.c is missing here:
https://github.com/ARMmbed/mbed-os/blob/master/connectivity/drivers/emac/TARGET_STM/TARGET_STM32F4/TARGET_NUCLEO_F429ZI/CMakeLists.txt#L11

[boraozgen]

Interesting... it calls the weak function in the HAL then... what a sneaky bug!

Thanks for the quick support @jeromecoutant !

[boraozgen]

I can confirm that this fixes the issue. Should I open a PR or do you want to check if other targets are affected @jeromecoutant ?

[jeromecoutant]

If you could do it for the 3 STM32F4 targets, I would be happy :-)

[0xc0170]

Thank you both !