1 ACCEPTED SOLUTION
Accepted Solutions
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:
- 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.
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).
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.
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:
- 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.
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).
