• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 2 answers
  • Subscribers 103 subscribers
  • Views 1573 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM5718: Pinmux PRUSS1 pin conflict

Daniel Sommerfeldt
Prodigy 245 points
Part Number: AM5718

I have loaded my pin mux file to the PinMux Tool. The file was created several times the last half year. No problems with the PRUSS pins in the past.

Now I have on the PRUSS1_MII1 pins a pin conflict.

What happens with the pin mux tool?

Is the PRUSS1_MMI1 no longer available on the AM5718?

Attached the PinMuxFile.PinMux File.zip

  • 0
    TI__Guru**** 393215 points
    The Pinmux team have been notified. They will respond here.
  • 0
    TI__Genius 13175 points

    Hello Dr. D,

    There were several changes made to the PRUSS1_MII to implement some PRUSS specific IP restrictions that I know of in the latest version. However, your combination looks valid and should not give you conflicts. Let me check with PRUSS experts and get back to you soon.

    Thanks for you patience, will reply here soon as I have things figured out.
    Alex

  • 0
    TI__Genius 13175 points
    Hello,

    To follow up on this since I have received some feedback from the design team. PRUSS1 MII0/1 have a HW dependency for using IOSET3/4. Basically If PRUSS1_MII0 uses IOSet3, then PRUSS1_MII1 must use IOSet4. PRUSS1_MII1 cannot use IOSet1. The reverse is also true. If PRUSS1_MII1 uses IOSet4, then PRUSS1_MII0 must use IOSet3. PRUSS1_MII0 cannot use IOSet1.

    In order to implement the above in the PMT and in order for you to be able to use this configuration without conflicts, we have to merge ioset3(MII0) and ioset4(MII1). This fix will be applied in the upcoming tool version which I believe should be out by end of month.

    Thanks,
    Alex
  • 0 in reply to Alex Bashkov
    Prodigy 150 points

    Hello,

    We are using the IOSet3 for PRUSS1 MII/0 and IOSet4 for PRUSS1 MII/1. Muxing is setup in U-Boot. I do see the PHY is able to establish a link on both ports, but I am unable to have any data transfered.
    The RX lines are busy, but nothing happens on the driver side. For the TX lines, all transmit data gets dropped and the lines are idle.

    For PRUSS2, both interfaces are working fine, but we use IOSet1 here.

  • 0 in reply to Michael Moese
    TI__Genius 13175 points
    Hello ,

    Is your muxing setup in U-Boot extracted from PinMux tool output files?

    Thanks,
    Alex
  • 0 in reply to Alex Bashkov
    Prodigy 150 points
    No, it is not. I've setup the PRUSS-Pin configuration manually, referring to the manuals and only using the pin assignment from the PinMux tool output.

    This is the muxing I have setup for PRUSS1:
    /* PRUSS1 MDIO */
    {VIN2A_D10, (M11 | PIN_OUTPUT)}, /* pr1_mdio_mdclk */
    {VIN2A_D11, (M11 |PIN_INPUT)}, /* pr1_mdio_data */
    /* PR1 MII0 */
    {VOUT1_D8, (M12 | PIN_INPUT_PULLDOWN)}, /* vout1_d8.pr1_mii_mt0_clk */
    {VOUT1_D9, (M13 | PIN_OUTPUT)}, /* vout1_d9.pr1_mii0_txd3 */
    {VOUT1_D10, (M13 | PIN_OUTPUT)}, /* vout1_d10.pr1_mii0_txd2 */
    {VOUT1_D11, (M13 | PIN_OUTPUT)}, /* vout1_d11.pr1_mii0_txen */
    {VOUT1_D12, (M13 | PIN_OUTPUT)}, /* vout1_d12.pr1_mii0_txd1 */
    {VOUT1_D13, (M13 | PIN_OUTPUT)}, /* vout1_d13.pr1_mii0_txd0 */
    {VOUT1_D14, (M12 | PIN_INPUT)}, /* vout1_d14.pr1_mii_mr0_clk */
    {VOUT1_D15, (M12 | PIN_INPUT)}, /* vout1_d15.pr1_mii0_rxdv */
    {VOUT1_D16, (M12 | PIN_INPUT)}, /* vout1_d16.pr1_mii0_rxd3 */
    {VOUT1_D17, (M12 | PIN_INPUT)}, /* vout1_d17.pr1_mii0_rxd2 */
    {VOUT1_D18, (M12 | PIN_INPUT)}, /* vout1_d18.pr1_mii0_rxd1 */
    {VOUT1_D19, (M12 | PIN_INPUT)}, /* vout1_d19.pr1_mii0_rxd0 */
    {VOUT1_D20, (M12 | PIN_INPUT)}, /* vout1_d20.pr1_mii0_rxer */
    {VOUT1_D21, (M12 | PIN_INPUT)}, /* vout1_d21.pr1_mii0_rxlink */
    {VOUT1_D22, (M12 | PIN_INPUT)}, /* vout1_d22.pr1_mii0_col */
    {VOUT1_D23, (M12 | PIN_INPUT)}, /* vout1_d23.pr1_mii0_crs */

    /* PR1 MII1 */
    {VIN2A_D3, (M12 | PIN_INPUT)}, /* vin2a_d3.pr1_mi1_col */
    {VIN2A_D4, (M13 | PIN_OUTPUT)}, /* vin2a_d4.pr1_mii1_txd1 */
    {VIN2A_D5, (M13 | PIN_OUTPUT)}, /* vin2a_d5.pr1_mii1_txd0 */
    {VIN2A_D6, (M11 | PIN_INPUT)}, /* vin2a_d6.pr1_mii_mt1_clk */
    {VIN2A_D7, (M11 | PIN_OUTPUT)}, /* vin2a_d7.pr1_mii1_txen */
    {VIN2A_D8, (M11 | PIN_OUTPUT)}, /* vin2a_d8.pr1_mii1_txd3 */
    {VIN2A_D9, (M11 | PIN_OUTPUT)}, /* vin2a_d9.pr1_mii1_txd2 */
    {VOUT1_VSYNC, (M12 | PIN_INPUT)}, /* vout1_vsync.pr1_mii1_rxer */
    {VOUT1_D0, (M12 | PIN_INPUT)}, /* vout1_d0.pr1_mii1_rxlink */
    {VOUT1_D1, (M12 | PIN_INPUT)}, /* vout1_d1.pr1_mii1_crs */
    {VOUT1_D2, (M12 | PIN_INPUT)}, /* vout1_d2.pr1_mii_mr1_clk */
    {VOUT1_D3, (M12 | PIN_INPUT)}, /* vout1_d3.pr1_mii1_rxdv */
    {VOUT1_D4, (M12 | PIN_INPUT)}, /* vout1_d4.pr1_mii1_rxd3 */
    {VOUT1_D5, (M12 | PIN_INPUT)}, /* vout1_d5.pr1_mii1_rxd2 */
    {VOUT1_D6, (M12 | PIN_INPUT)}, /* vout1_d6.pr1_mii1_rxd1 */
    {VOUT1_D7, (M12 | PIN_INPUT)}, /* vout1_d7.pr1_mii1_rxd0 */

    This is the muxing setup for the working PRUSS2:

    /* PRUSS2 MDIO */
    {MCASP1_ACLKX, (M11 | PIN_OUTPUT)}, /* pr2_mdio_mdclk */
    {MCASP1_FSX, (M11 | PIN_INPUT)}, /* pr2_mdio_data */
    /* PRUSS2 MII0 */
    {MCASP3_FSX, (M11 | PIN_INPUT)}, /* pr2_mii0_col */
    {MCASP3_ACLKX, (M11 | PIN_INPUT)}, /* pr2_mii0_crs */
    {MCASP1_AXR13, (M11 | PIN_INPUT)}, /* pr2_mii_mr0_clk */
    {MCASP1_AXR1, (M11 | PIN_INPUT)}, /* pr2_mii_mt0_clk */
    {MCASP2_AXR2, (M11 | PIN_INPUT)}, /* pr2_mii0_rxd0 */
    {MCASP2_FSX, (M11 | PIN_INPUT)}, /* pr2_mii0_rxd1 */
    {MCASP2_ACLKX, (M11 | PIN_INPUT)}, /* pr2_mii0_rxd2 */
    {MCASP1_AXR15, (M11 | PIN_INPUT)}, /* pr2_mii0_rxd3 */
    {MCASP1_AXR14, (M11 | PIN_INPUT)}, /* pr2_mii0_rxdv */
    {MCASP1_AXR0, (M11 | PIN_INPUT)}, /* pr2_mii0_rxer */
    {MCASP1_AXR12, (M11 | PIN_OUTPUT)}, /* pr2_mii0_txd0 */
    {MCASP1_AXR11, (M11 | PIN_OUTPUT)}, /* pr2_mii0_txd1 */
    {MCASP1_AXR10, (M11 | PIN_OUTPUT)}, /* pr2_mii0_txd2 */
    {MCASP1_AXR9, (M11 | PIN_OUTPUT)}, /* pr2_mii0_txd3 */
    {MCASP1_AXR8, (M11 | PIN_OUTPUT)}, /* pr2_mii0_txen */
    /* PRUSS2 MII0 */
    {XREF_CLK0, (M11 | PIN_INPUT)}, /* pr2_mii1_col */
    {XREF_CLK1, (M11 | PIN_INPUT)}, /* pr2_mii1_crs */
    {MMC3_DAT2, (M11 | PIN_INPUT)}, /* pr2_mii_mr1_clk */
    {GPIO6_10, (M11 | PIN_INPUT)}, /* pr2_mii_mt1_clk */
    {MMC3_DAT7, (M11 | PIN_INPUT)}, /* pr2_mii1_rxd0 */
    {MMC3_DAT6, (M11 | PIN_INPUT)}, /* pr2_mii1_rxd1 */
    {MMC3_DAT5, (M11 | PIN_INPUT)}, /* pr2_mii1_rxd2 */
    {MMC3_DAT4, (M11 | PIN_INPUT)}, /* pr2_mii1_rxd3 */
    {MMC3_DAT3, (M11 | PIN_INPUT)}, /* pr2_mii1_rxdv */
    {MCASP3_AXR0, (M11 | PIN_INPUT)}, /* pr2_mii1_rxer */
    {MMC3_DAT1, (M11 | PIN_OUTPUT)}, /* pr2_mii1_txd0*/
    {MMC3_DAT0, (M11 | PIN_OUTPUT)}, /* pr2_mii1_txd1*/
    {MMC3_CMD, (M11 | PIN_OUTPUT)}, /* pr2_mii1_txd2*/
    {MMC3_CLK, (M11 | PIN_OUTPUT)}, /* pr2_mii1_txd3*/
    {GPIO6_11, (M11 | PIN_OUTPUT)}, /* pr2_mii1_txen*/
  • 0 in reply to Michael Moese
    TI__Genius 13175 points

    ,

    OK, I have quickly reviewed you configuration for PRU1 MII0/1 and it looks good. Are you also configuring the PRUss internal wrapper mux? Here is what the tool also gives me as an additional register to set:

    MII0

    /** {ALTERNATE_PADCONF_ADDRESS/PRUSS_REG_ADDRESS, ALTERNATE_PADCONF_VALUE/PRUSS_REG_VALUE} **/

     0x4B2A6008      0x10000000       

     

    MII1

    /** {ALTERNATE_PADCONF_ADDRESS/PRUSS_REG_ADDRESS, ALTERNATE_PADCONF_VALUE/PRUSS_REG_VALUE} **/

    0x4B22600C       0x10000000

    Thanks,

    Alex

  • 0 in reply to Alex Bashkov
    Prodigy 150 points
    Hi again,
    I added the setting of the two registers as you suggested, without success. We checked again our muxing and found the following:

    Like on the evaluation board, pr1_mii1_txd0 is configured (and wired) to use ball F4 from the AM5718. The pinmux tool says for using the pin as pr1_mii1_txd0, the mode should be 24. What does this mode mean? According to the manuals and source code available, the mux mode is 0..15?

    In addition, the "AM571x Sitara Processors Silicon Revision 2.0 (Rev. D)" manual does not list F4 as a valid ball for pr1_mii_txd0, but "pr1_pru1_gpo2" , (see Table 4-2. Ball Characteristics).

    Table 7-152.PRU-ICSS1 IOSETs does list this pin in IOSET4, as it is intended. For

    Is this just confusing me?

    MDIO seems to work fine, I get link status change messages for the Ethernet devices. When measuring, the clocks from the PHYs are both at 25MHz and look good. The rxd-lines show traffic when measuring the lines, the txd lines remain idle.

    Do you have any hints how we can find out what is wrong here?
  • 0 in reply to Michael Moese
    TI__Genius 13175 points

    Hi ,

    Correct muxmodes are limited to 0..15 from the original muxmode register. However there are the nested (alternate) options from the PRUss internal wrapper (basically the internal PRUSS ip has its own muxmode layer). We cannot really display these in the pinmux tool as nested muxing, so we had to add on the additional alternate options on top of the 0..15 muxing resulting in more than 16 options (in your case you are using the 24th option.)

    The data manual probably just lists only the "original" PRUSS signals in the "Ball Characteristics" table as the alternate internal multiplexing is IP specific. Hope this clarifies it now.

    That above is from PinMux tool perspective. And all I can see is good and should work. Let me try to bring in here the PRUss experts if they can spot anything wrong. Will let you know soon.

    Thanks,
    Alex

  • 0 in reply to Alex Bashkov
    Prodigy 150 points
    Hi,
    Any news on this topic?


    Michael
  • 0 in reply to Michael Moese
    TI__Genius 13175 points
    No, not yet, let me remind PRU team again. Thank you for your patience.

    Alex
  • 0 in reply to Alex Bashkov
    TI__Genius 15180 points

    Hi,

    The alternate pinmuxing for the MII2 mode actually needs to be set in three (3) registers:

    0x4B22600C (PRUSS_GPCFG1 for PRU-ICSS1) = 0x40000000
    0x4B2A6008 (PRUSS_GPCFG0 for PRU-ICSS2) = 0x40000000
    0x4B2A600C (PRUSS_GPCFG1 for PRU-ICSS2) = 0x40000000

    This is also described in section 30.2.1 of the AM571x TRM-- see MII2 mode in Table 30-1 & 30-2.  Can you confirm that you are configuring all 3 of these registers?

    Also, what AM571x silicon revision are you using? SR2.0?

    Regards,

    Melissa

  • 0 in reply to melissaw
    Prodigy 150 points

    Hi Melissa,

    I am setting these up in U-Boot, yes. However, this should not even be needed as drivers/net/ethernet/ti/prueth.c does this:

     pruss_cfg_gpimode(pruss, prueth->pru0, PRUSS_GPI_MODE_MII);
 pruss_cfg_gpimode(pruss, prueth->pru1, PRUSS_GPI_MODE_MII);
 pruss_cfg_miirt_enable(pruss, true);
 pruss_cfg_xfr_enable(pruss, true);

    I did not need to do anything special fur PRUSS2. 

    We are on Silicon Revision 2.0.

  • 0 in reply to Michael Moese
    Prodigy 150 points
    I still cannot see an issue here what we have wrong - any help would really be appreciated.
  • 0 in reply to Michael Moese
    TI__Genius 13175 points
    Hi ,

    We are shooting in the dark without an error log or a pointer to where the issue may be. So, let's try a clean configuration directly from pinmux tool generated files. Could you please configure the PRUSS as needed in latest PMT version, generate pin configuration and use that "as is" in your driver? Please try this approach and let us know if it works for you. If that does not work out, then it must be something else (non pinmux related).

    Thanks,
    Alex