• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 533 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: MDIO user command only

Jiri Dobry
Expert 1810 points
Part Number: TMS570LC4357

Hello,

we would like to connect SMSC LAN9303 ethernet switch directly to TMS570LC4357 EMAC. In basic configuration it work without problem. But for  the advanced configuration we need to send some configuration data over MDIO interface. Problem is that it need pair of MDIO packets without another MDIO cycle. Hercules have two MDIO user acccess registers. But state machine on background still works and always interlace this two user commad. (Control registers of the LAN9303 are mapped as PHYADR 0x10-0x1F. Link status state machine polling all 32 PHYs.)
Is it any way to send two MDIO user command as pair without interruption from link status state machine? Or is it possible to stop this state machine? Or is it possible some manipulation with MDIO enable to send only one (user) MDIO command? Is is possible limit link status state machine range?

I am trying to find any possibility in MDIO control registers, but without sucess.

  • 0
    TI__Guru 68920 points
    Hi Jiri,

    Good question but I don't think there is any way to disable the continuous polling of link status.

    Did you try to use USERACCESS0 followed by USERACCESS1 so that both have 'GO' set? it does mention in the TRM that there is 'round robin arbitration' so maybe having the other USERACCESS1 ready to "GO" when USERACCESS0 completes will block the interruption of the background polling.

    That's just a wild guess. We'd need to do some research of internal docs to see if we can find something to back that guess up if it happens to work because I don't see it clearly described in the TRM chapter [the arbitration between USER and the continuous link active polling].
  • 0 in reply to Anthony F. Seely
    Expert 1810 points

    Hi Anthony,

    of course I try to write USERACCESS0 followed by USERACCESS1 close together as is possible. But it still interleaved by state machine continuous pooling.

    We are modify prototype HW already. I write this email, because I need confirmation, that HW modification is absolutely needed. Some guys (include me) don't like second option with  I2C communication, because I2C have problem with electomagnetic field jamming often. 

    Jiri

  • 0 in reply to Jiri Dobry
    TI__Guru 68920 points
    Hi Jiri,

    So I think I did all that I can do in a reasonable amount of time:

    1) I dug up the internal design spec for the MDIO.
    Unfortunately there's not a lot of implementation detail i.e. state diagrams like some other specs.
    Basically the same text that you see in the TRM.

    2) I looked through the source code for the scheduler submodule inside the MDIO.
    I didn't try to extract the state diagram from the code... that would take a considerable amount of time.
    And there's not a lot of comments.

    From what it looks like -- after you perform a user access it looks like it moves on to the 'next phy'
    to do something. There's some dependency there like if the phy has responded or not that complicates
    understanding it fully in a short amount of time.

    Anyway in a nutshell:
    a) I'm not seeing even any 'whiff' of the ability to lock two user accesses back to back.
    b) the spec does say that the purpose of the USERACCESS0, USERACCESS1 is to allow you to queue up a second access while one is in progress. doesn't say anything about locking them together.
    c) reading through the specs it looks like the MDIO is designed to handle up to two PHYs for cases where there are two MACS.
    and it really does look like it's designed to alternate between the two phys ...

    So I'm guessing you might be seeing it try to talk to the 2nd phy or scan for a 2nd phy after the user access ... that's what the code looks like it would do ... And while I can't prove this; I don't see anywhere any discussion or signal name or state name that would indicate you can lock two user accesses together.

    So I'd say with > 90% confidence the answer is unfortunately 'no' there isn't a way.

    Best Regards,
    Anthony