• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1048 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.

RTOS/AM5728: Running NIMU Basic Example on M4 with Port 1

Devon Clark
Prodigy 230 points

Part Number: AM5728

Tool/software: TI-RTOS

I am trying to run the NIMU Basic Example for M4 on ethernet port 1 on our custom board. By default, the app runs on ethernet port 0. I want to run it on port 1 because port 0 on our custom board is not currently functional due to a hardware issue. I have tried many different ways to get the app to use port 1 instead of port 0, but all have been unsuccessful. If someone could explain to me how to correctly go about this, that would be greatly appreciated. It is also important to note that this example must run on the M4 (i.e. I can't use the dual MAC example that runs on the ARM) because we currently cannot boot into the A15.

  • 0
    TI__Mastermind 43296 points
    Devon,

    Does the EMAC_BasicExample_idkAM572x_m4BiosExampleProject (note: without NIMU) work on your custom board? It the example works fine your board, then it's just a matter of setting up second port IP address issue and you can refer to A15 project to update .cfg and main.c file.

    The emac driver example driver will help you narrow down the issue to see if it's PHY link failure or other packet send/receive problem, and you can always add the driver c file to the CCS project for debugging.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 230 points

    A little more background on my configuration - on our custom board, we do not have the two Gigabit Ethernet PHYs (KSZ9031RN) connected to our processor. Instead, we have a 5 port unmanaged switch (KSZ8895MQX) connected to RGMII0 and a 3 port unmanaged switch (KSZ8873MLLI) connected to RGMII1. The switches have built in PHYs, and we are assuming that the MAC is provided by the processor (because there does not appear to be any external MACs on the IDK). As I mentioned earlier, the three port switch (RGMII1) is non functional due to a hardware issue, so I am focusing on just bringing up the 5 port switch.

    Now, EMAC_BasicExample_idkAM572x_m4BiosExampleProject does not work on our custom board. I believe I have found at least part of the problem though, and that is that the EMACInitCfg (located in emac_soc.c) has the phy_addr fields set to the wrong PHY addresses. On our board, RGMII0 is actually connected to PHY 5 on the 5 port switch. Switching the phy_addr for port 0 of EMACInitCfg from 0 to 5, I can see that the PHY acknowledges the MDIO register read for link status. The link does not actually come up, but this confirms that I am at least talking to the correct port now. I presume now I have to figure out how to bring up that interface.

    A few more questions I have:

    • I see a lot of references to "port" within the EMAC code. Many functions take this as a parameter (Ex. emac_poll_phy(uint32_t port)). Can you explain what this port pertains to? Does port # correspond to RGMII#?
    • Furthermore, I noticed that app_get_mac_addr() only accepts port values of 1 or 2. Is this the same port number as I mentioned in my previous question? If so, why is it one indexed instead of zero indexed?
    • Does this app send packets between two ports or does it do a loopback on a single port?

  • 0 in reply to Devon Clark
    TI__Mastermind 43296 points
    Devon,

    Yes, the 'port' is the RGMII# and the example code appears to have mixed index which should be cleaned up.
    The app send packets on a single port and do a loopback.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    TI__Mastermind 43296 points
    Devon,

    Were you able to root cause the link issue and able to run NIMU basic example from M4?

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 230 points

    We discovered last night that the network switch we were using only supports MII and not RMII. Since the pins for RMII on the AM572x are not the same as MII, this is unfortunately a hardware issue (Either re-route to the correct pins and change pinmux, or replace the switch chip). Thankfully there are RMII versions of the chips we are using and the pin layout lines up with the existing RGMII interface, so it is just a BOM change for us. We will be overnighting the correct chips and hopefully swapping them out tomorrow early afternoon. I should have results later in the afternoon.

  • 0 in reply to Devon Clark
    Prodigy 230 points

    Update: We have now realized that RMII is not the same as RGMII, which is how the IDK board/pinmux are set up to support the GB PHY. Our switch is only 10/100, and there is no close alternative version that supports the RGMII interface. Therefore, we will in fact have to rework the board (not just a BOM change as originally expected). Since we have to rework the board either way, we decided to replace the MII switch with an RMII switch because the reworks needed to support this reduced interface are much easier (about half the effort) than if we were to rework for MII interface. We are aiming to have results on whether or not these changes work by late tomorrow evening.

  • 0 in reply to Devon Clark
    TI__Mastermind 43296 points
    Devon,

    It appears the issue is hardware related. I am closing the e2e and certainly you can re-open it or create a new one if you have any difficulty to port the NIMU sw example on your board.

    Regards,
    Garrett
  • 0 in reply to Garrett Ding
    Prodigy 230 points

    Apologies for not responding sooner. It was in fact a hardware issue. The issue was that we were trying to connect to one of the PHYs on the network switch via MII, but on this particular switch (KSZ8895MQXIA), when accessing the PHY via MII, the PHY becomes isolated from the rest of the switch fabric. The switch does also support a MAC -> MAC MII connection, however, from what I have read on the forums, the TI Sitara line of processors does not support MAC -> MAC MII connections. In order to resolve this issue, we connected the AM5728 MAC to an external PHY via MII and connected the Rx/Tx pairs of the external PHY to one of the PHY ports on the switch. With this configuration, the NIMU app now works and we are able to talk to the Sitara via all 4 externally facing ports of the switch.