cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 (with Cube 1.40) ethernet MDIO usage for PHY manufacturer SMI interface with custom opcode

avik.de
Associate II

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:

  • directly modify ETH->MACMDIOAR directly to set the PA and RDA bits as required by the KSZ8863 Table 3-9 (instead of HAL_ETH_ReadPHYRegister)
  • set MACMDIODR to 0
  • set the C45E bit of MACMDIOAR (I am not sure about this and if that makes sense for this PHY, but RM0433 says "When Clause 22 PHY is enabled, only Write and Read commands are valid.")
  • Set the GOC bits of MACMDIOAR to 00 (despite it being "reserved" according to RM0433)

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.

1 ACCEPTED SOLUTION

Accepted Solutions
avik.de
Associate II

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:

0690X000008BRRiQAO.png

To do this:

  • set ETH_MACMDIOAR_PA, ETH_MACMDIOAR_RDA as shown in the table ^
  • set ETH_MACMDIOAR_MOC to 0x0
  • set MACMDIODR to the (16 bits of) data you want to send
  • DO NOT SET the C45 bit
  • set ETH_MACMDIOAR_MB

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.

0690X000008BYyaQAG.png

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:

0690X000008BYyfQAG.png

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).

View solution in original post

6 REPLIES 6
avik.de
Associate II

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)

0690X000008BRRYQA4.png

0690X000008BRRiQAO.png

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.

avik.de
Associate II

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:

0690X000008BRRiQAO.png

To do this:

  • set ETH_MACMDIOAR_PA, ETH_MACMDIOAR_RDA as shown in the table ^
  • set ETH_MACMDIOAR_MOC to 0x0
  • set MACMDIODR to the (16 bits of) data you want to send
  • DO NOT SET the C45 bit
  • set ETH_MACMDIOAR_MB

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.

0690X000008BYyaQAG.png

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:

0690X000008BYyfQAG.png

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).

y.rr
Associate II

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 :)

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.

minchingho_span
Associate II

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. 

elidonner
Associate II

@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:

elidonner_0-1722875400993.png

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.