2019-05-08 08:35 AM
I am trying to use the KSZ8863 IC and (as shown in Table 3-9 of its datasheet) it has many configuration options behind a tweaked version of the standard MIIM interface. In particular, the opcode needs to be set to 00.
I have tried the following:
This results in a garbage reading. I don't at present have a way to probe the MDIO physical line, so any advice about if this should be possible, and other register settings to try, would be very helpful.
EDIT: forgot to mention that HAL_ETH_ReadPHYRegister works fine for reading the standard PHY registers, so the hardware connections seem OK.
Solved! Go to Solution.
2019-05-12 10:48 AM
For any future users who stumble across this: I got a logic analyzer and it turns out that even though it is not "allowed" in the RM, it is possible to use the SMA peripheral to execute the custom "write" instruction:
To do this:
This results in the following transmission on the wire: note that OP=00 despite it being listed as "reserved" in the RM, with the desired ST=01. I am just sending (bogus) data 0x1234 to register 0 as an example. EDIT: I have also verified that the write is accepted by the device.
The bad news is that the custom read instruction does not work. Here is an example where I have done everything as in the write, but also cleared DR, and asserted the high bit of PA:
You can see that the everything till the turnaround is correct, but the data is 0. I assume this is because the STM32 is driving the MDIO line since it does not know that this is a read command, and the device (KSZ8863) cannot drive it.
I cannot find any other (documented) bits in ETH_MACMDIOAR that could possibly affect this behaviors so at this point I am being forced to give up on this and assume bit-banging is the only way this peripheral could be used for this protocol. For ST engineers: it would be great if there could be just a tiny bit more flexibility in this peripheral (perhaps one of the reserved bits of ETH_MACMDIOAR could be used to explicitly signal if the data line should be driven or Hi-Z).
2019-05-08 08:06 PM
Except for the op code (which seems to suggest using the clause 45 bit), I notice that the protocol calls for "01" for the "start of frame" as shown in these tables (first regular MIIM, then the modified SMI)
However, it seems like the "start of frame" for clause 45 mode is 00 https://www.totalphase.com/support/articles/200349206-MDIO-Background
I have also looked at this other post https://community.st.com/s/question/0D50X00009XkgMuSAJ/stm32f7-clause-45-mdio where the suggested solution was bit-banging, but it is also true that the clause 45 bit appears to be new in this H7 compared to the chip referenced in that post.
Thanks for any help.
2019-05-12 10:48 AM
For any future users who stumble across this: I got a logic analyzer and it turns out that even though it is not "allowed" in the RM, it is possible to use the SMA peripheral to execute the custom "write" instruction:
To do this:
This results in the following transmission on the wire: note that OP=00 despite it being listed as "reserved" in the RM, with the desired ST=01. I am just sending (bogus) data 0x1234 to register 0 as an example. EDIT: I have also verified that the write is accepted by the device.
The bad news is that the custom read instruction does not work. Here is an example where I have done everything as in the write, but also cleared DR, and asserted the high bit of PA:
You can see that the everything till the turnaround is correct, but the data is 0. I assume this is because the STM32 is driving the MDIO line since it does not know that this is a read command, and the device (KSZ8863) cannot drive it.
I cannot find any other (documented) bits in ETH_MACMDIOAR that could possibly affect this behaviors so at this point I am being forced to give up on this and assume bit-banging is the only way this peripheral could be used for this protocol. For ST engineers: it would be great if there could be just a tiny bit more flexibility in this peripheral (perhaps one of the reserved bits of ETH_MACMDIOAR could be used to explicitly signal if the data line should be driven or Hi-Z).
2019-09-16 04:46 AM
hey There :)
I'm stuck trying to access the Registers of the KSZ8863RLL
I'm using the STM32F767 with STM32CubeIDE Version: 1.0.2.
I can read and write the MIIM Registers via HAL_ETH_WritePHYRegister
also ethernet communication is working fine.
But i can't find the way to use the MDIO interface with OP code '00' to be able to get to all the other registers.
So can someone help me?
To the reply by avik.de:
I dont have ETH_MACMDIOAR_MOC and the other things you wrote. Or at least I could not find them...
I would be really happy if one can help me :)
2023-12-01 01:22 PM
I have went through the same problem. Same thing happens on STM32H5. The SMI read always returns 0. I have not tried to write the register ( stopped doing anything when I found read is not working ). Will try it and provide update later.
2023-12-04 11:20 AM
Follow up on this, I can confirm the write operation does work to KSZ8863 as the original solution states.
Hope this can help others who ran into the same problem.
2024-08-05 09:22 AM - edited 2024-08-05 09:37 AM
@avik.de major kudos for this great dive. Saves me a lot of time.
For other's with same question as @y.rr , the ETH_MACMDIOAR... referenced in the original post comes from the reference manual. If you are looking at code generated by STM32CubeMX (stm32f4xx_hal_eth.h), the registers are defined as ETH_MACMIIAR...
Specifically for the OpCode, "I no longer see ETH_MACMDIOAR_MOC", you could edit the MII write code, which is in the register ETH_MACMIIAR_MW_Msk.
As mentioned by OP ( @avik.de ), I similarly do not see a way to set the dataline to HiZ.EDIT: from the Reference Manual, it seems the default for the SMI frame format is HI Z in the turnaround:
It seems plausible that the 10 in the operation being overwritten with 00 inhibits this HI Z default for the read operation.
Curious for others if anyone has found decent way for disconnecting the MIIM (MDIO/MDC) entirely to not waste the GPIO? I'd rather opt to use the I2C or SPI interface also available with the KSZ8863. I could simply not configure the 2 GPIO corresponding to MDIO/MDC, but unsure if this would fully disable the MIIM bus. Happy for a pointer to a piece of documentation as well.