Posted on May 23, 2017 at 02:00Hi,
I am having some issues with the Cube generated Ethernet startup code. I suspect I am discovering limitations in the generated code because of assumptions Cube is making of my hardware.
For reference my setup is as follows:
MCU: STM32F427ZITx on a custom made PCB
Cube: STM32Cube FW_F4 V1.13.1
IDE: System Workbench V1.11.0.201610101240
PHY: MICREL KSZ8863MLL Integrated 3-Port 10/100 Managed Switch with 2 PHYs
Access to PHY control registers using MIIM
The issues I am faced with include:
1. Cube assumes I have a single PHY. In my instance I need to configure 2 PHY. This involves modifying the HAL Ethernet driver. There are no user blocks so I'm unsure how to make the necessary changes.
2. Cube assumes I can perform certain functions on the PHY. For example, it assumes I can do a soft reset using register 0. This is not supported on my PHY. Performing a reset overrides the register defaults and put the PHY into an unexpected state.
3. Cube assumes I have access to the extended registers. The MIIM interface gives me limited access to registers. If I enable auto-negotiation, the last step of Ethernet initialisation in the HAL driver is to read back the Ethernet speed and duplex. Since I can't access the extended registers, the resulting values to the read call (which passes) is 0xFF. Further processing on the value read back results in unintended behavior.
My question is, how do I modify the HAL Ether initialisation routine? These best way forward I can see so far is to take a copy of the generated code I have so far, turn of Cube code generation for the Ethernet interface, copy the code back into my project and modify it to suit. Is this how I should proceed?
Regards, Matt.
#ksz8863 #hal_eth_init #micrel
