Hi, the datasheet for UbiSwitch tells MDIO signals should only be used when the switch is in reset. I see there is the ETH_RST line broken out to the mating header, but I don’t see a connector with this signal on the large baseboard. There is a testpoint labeled ERST, though. So is the signal broken out there? How am I supposed to put the switch to reset if this testpoint is between the baseboard and the module, so physically inaccessible?
Forgive the delay, team was offline for a few days.
Where did you find that in the datasheet? That’s definitely not the case and the MDIO signals should be used when the switch is not in reset. Please share a link or image and if that’s a typo, we’ll need to fix that.
ETH_RST isn’t really designed to be broken out, and instead is just manipulated by the onboard microcontroller.
Though I suppose, if you’re using the MDIO signals broken out on the baseboard, it might be useful to also include the switch hardware reset signal on the baseboard too. In the end we ended up somewhat running out of pins on the stacking connectors though (unless we removed one of the grounds which we didn’t want to do as it would have removed the symmetry), and we figured that most people are not going to be talking to the switch over MDIO from the baseboard, and if they are, they can just initiate a reset by using the internal registers of the switch.
Thanks. I got the information from Rev. H UbiSwitch datasheet (MDC_CPU):
It’s talking about INTn pin of the switch, but as the switch datasheet is not public, the best thing I could map this name to was the ETH_RST signal.
Yes, that’s INTn, which is the global interrupt pin on the 88E6393, not RSTn.
INTn will go high if you configure and enable interrupts on the chip in the Switch Global Control Register. By default, interrupts are not enabled, so you don’t need to worry about INTn ever going high. It will only go high if you configure and enable interrupts over MDIO, and interrupts are disabled by default on the 88E6393. If you do enable interrupts and end up locking yourself out of the MDIO, a hardware reset would solve it.
So I guess there is a potential case where a user enables global interrupts, cannot access the MDIO bus, and cannot initiate a hardware reset on the UbiSwitch BaseBoard. This is a bit of an edge case though, as we don’t really expect many customers to be using the MDIO bus… To be honest, the thinking of breaking it out was so that we could diagnose problems on the MDIO bus between the MCU and the switch.
Anyway, just don’t enable interrupts on the chip and you’ll be fine.
1 Like
Thanks for the explanation!
1 Like