RTOS ThreadX with NetXDuo in CubeMX uses a lan8742 driver file called nx_stm32_phy_driver.c wherein the HAL calls have too many variables. Has this been reported?

[GGree.1]

The calls in particular are HAL_ETH_ReadPHYRegister and HAL_ETH_WritePHYRegister. In the HAL driver files, specifically stm32f7xx_hal_eth.c, these routines take 3 variables and not 4.

For example, in the nx_stm32_phy_driver.c, the function for Read is:

HAL_ETH_ReadPHYRegister(&eth_handle, DevAddr, RegAddr, pRegVal)

and in the HAL drivers the function is :

HAL_ETH_ReadPHYRegister(ETH_HandleTypeDef *heth, uint16_t PHYReg, uint32_t *RegValue)

Since there are no examples of NetXDuo usage as created by CubeMX, I am having a hard time trying to figure out if this is a bug or simply a configuration issue.

[Walid ZRELLI]

Hello @Community member​ ,

This is a known limitation and it’s mentioned in Release Notes.

For F4 and F7, HAL is modified vs. the HAL available in CubeMx, so you need to use the HAL driver provided in the Pack, not the one available in CubeMX.

Future updates on STM32F7/F4 CubeFW and STM32CubeMX will align the HAL ETH driver to the one used by Azure RTOS Pack.

BeST Regards,

Walid

[GGree.1]

So does that mean that a project for stm32F746G Disco needs to be done by hand without the use of CubeMX? I know that if I use CubeMX to make assignments then it will replace all the HAL Drivers with the Repo contents from STM32Cube_FW_F7_V1.16.2 and not from the X-CUBE-AZRTOS-F7/PACK. Or is there a way to tell CubeMX not to pull over the HAL Drivers from the STM32Cube_FW_F7_V1.16.2?

[GGree.1]

Possibly to answer my own question, I guess I could pull up the properties for each of the HAL files and and change to link to the X-CUBE-AZRTOS-F7/PACK but will CubeMX in CubeIDE adhear to the link or do its own thing?