• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 426 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.

Can I pin_mux like this?

Lihua Zhu
Intellectual 900 points

Hi,

I'm using a st16c554 which use address bus, and also I'm using a secondary MAC interface which use gpmc_a[11, 10, 5, 4, 0] as mii interface.

Can I pin_mux as below? that is, partially of the gpmc_a[21:0] used for mii, and other of  them used as address bus?

static struct pinmux_config rmii2_pin_mux[] = {
        {"gpmc_wait0.rmii2_crs_dv", OMAP_MUX_MODE3 | AM33XX_PIN_INPUT_PULLDOWN},
        {"gpmc_wpn.mii2_rxerr", OMAP_MUX_MODE3 | AM33XX_PIN_INPUT_PULLDOWN},
        {"gpmc_a0.mii2_txen", OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT},
        {"gpmc_a4.mii2_txd1", OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT},
        {"gpmc_a5.mii2_txd0", OMAP_MUX_MODE3 | AM33XX_PIN_OUTPUT},
        {"gpmc_a10.mii2_rxd1", OMAP_MUX_MODE3 | AM33XX_PIN_INPUT_PULLDOWN},
        {"gpmc_a11.mii2_rxd0", OMAP_MUX_MODE3 | AM33XX_PIN_INPUT_PULLDOWN},
        {"mii1_col.rmii2_refclk", OMAP_MUX_MODE1 | AM33XX_PIN_INPUT_PULLDOWN},
        {"mdio_data.mdio_data", OMAP_MUX_MODE0 | AM33XX_PIN_INPUT_PULLUP},
        {"mdio_clk.mdio_clk", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT_PULLUP},
        {NULL, 0},
};

static struct pinmux_config st16c554_pin_mux[] = {
        {"gpmc_csn1.gpmc_csn1", OMAP_MUX_MODE0 | AM33XX_PULL_DISA},
        {"gpmc_a1.gpmc_a1", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {"gpmc_a2.gpmc_a2", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {"gpmc_a3.gpmc_a3", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {"gpmc_a6.gpmc_a6", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {"gpmc_a7.gpmc_a7", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {"gpmc_a8.gpmc_a8", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {"gpmc_a9.gpmc_a9", OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT},
        {NULL, 0},
};      

Thank you.

Lihua

  • 0
    TI__Guru**** 393215 points
    Hi Lihua,
     
    Yes, you can. No problem.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 900 points

    Hi Biser,

    Thank you very much.

    Now my problem is the st16c554 is working fine, but the rmii2 doesn't.

    I sniffered with wireshark, and I can see there are ARP packages send out, but the board can't receive anything. further probe shows it never enters interrupt service routine when trying to receive data.

    following message shows when booting up.

    configuring  network parameters and ENV VAR...
    [    5.647735] net eth1: CPSW phy found : id is : 0x20005c90
    [    5.665008] net eth0: CPSW phy found : id is : 0x20005c90

    And I can see some data on the RXD[1:0], CRS_DV with an oscilloscope.

    Where I might go wrong?

  • 0 in reply to Lihua Zhu
    TI__Guru 62855 points

    The messages you mentioned in your post are based on register reads via MDIO and do not indicate you have valid data paths between the MAC and PHY.  However, it sounds like transmit is working. 

    What a re you using to source the 50MHz RMII clock?

    Regards,
    Paul

  • 0 in reply to peaves
    Intellectual 900 points

    Thank you Paul,

    Yes, I think the transmit is working. It send ARP packets when I ping my host machine, and the host replied. And every ping will enter interrupt service routine. But it never get a packet.

    We use an external crystle oscilator for the 50Mhz RMII clock, and I have set bit 6 and 7 of  MII_SEL register.

    any other ideals?

    Best regards,

    Lihua

  • 0 in reply to Lihua Zhu
    TI__Guru 62855 points

    What is the jitter performance of this crystal oscillator.  It needs to be a very low jitter clock source like you get with a 50 MHz fundamental mode crystal oscillator.

    You can not use a crystal oscillator that has an internal PLL that allows you to program a 50 MHz output because most of these crystal oscillators have too much jitter.

    I have seen this type of problem on receive data several times.  This can occur because the PHY is receiving data from the Ethernet cable using a clock recovered from the receive data and then it must synchronize this data from the recovered clock domain to the 50MHz RMII clock domain.  If the RMII clock jitter is too large the PHY will not properly synchronize the receive data across clock domains.

    You can connect a logic analyzer to the RMII receive signals and manually verify the receive data is what you expect coming out of the PHY.  This we tell you if the problem is in the PHY or the MAC side of RMII.

    Regards,
    Paul

  • 0 in reply to peaves
    Intellectual 900 points

    I'm  using a oscillator with power input and directly output square waveforms. It should be a low jitter one. I have 2 ether net port on the board, and the first is working fine. And I tested with another board, got the same result. The 2nd eth port doesn't work.

    I'll analize with a logic analyzer to see if the data come from phy is correct. But I don't know how to interpret the rmii signal. Do you know where can I get the document? I googled "rmii interpret" and read the DP83848 datasheet, and got no result.

    Thank you very much.

    best regards,

    Lihua