• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 98 subscribers
  • Views 1299 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.

Two RMII and 16 bits external bus after some tweaks: is this design valid?

Marcelo Barros
Intellectual 365 points
Other Parts Discussed in Thread: TS5A3157

Hello

I have been using the pin mux utility and searching for a solution for my design. I need two RMII interfaces and a 16 bits external bus besides other less important peripherals (MMC is not required, we can use USB). The default I/O sets do not allow me any valid combination but it seems possible to do it with some tweaks.
After selection the “IO Set 14” for GEMAC (two RMIIs), I selected “IO Set 26” for GPMC, but with the following changes:

PinMux Setup: 6786.2xRMII_GPMC16Ext_AM335x.zip

  • Deselect GPMC_A26_MUX0 (it conflicts with RMII2_RXD1)
  • Deselect GPMC_A27_MUX0 (it conflicts with RMII2_RXD0)
  • Deselect GMPC_WAIT0 (it conflicts with RMII2_CRS_DV)
  • Deselect GMP_WPN (it conflicts with RMII2_RXER)

From my point of view, the consequences are:

  • External 16 bits devices with 64MB per chip select.
  • Only asynchronous memories are allowed since GMPC_WAIT1 is used instead GPMC_CLK_MUX0 and the wait pin is required for NANDs/NORs memories. But you can select GPMC_CLK_MUX1 instead of CPMC_CSN1 if synchronous memory is an issue for you.
  • No write protection pin for flash. But I believe we can use a GPIO for this purpose.

My question is: given the limitations, is this design valid? Is it really possible to deselect part of the bus?


Thanks a lot
Marcelo Barros


PS: After this initial setup, it is also possible to add RTC, I2C0, MDIO, SPI0, SPI1, TIMER4, TIMER7, UART0, UART1, USB0, USB1, ADC, EMIF, DEBUGSS, GLUE, OSC0, OSC1_RTC. Four chip selects are available as well. However, it seems not possible to have MMC.


  • 0
    TI__Expert 6735 points

    Marcelo:

    In Pin Mux Utility, could you do a File -> Save -> Design and post the file.  (Might need to rename to *.txt.)

    Regards,

    Michael T

     

  • 0 in reply to Michael T
    Intellectual 365 points

    Hello Michael

    I did it in my post, see "PinMux Setup" 6786.2xRMII_GPMC16Ext_AM335x.zip

    (.dat is inside a .zip file)

    Thanks

    Marcelo

  • 0
    TI__Guru 62855 points

    Selecting pin functions by selecting one of the valid IO Sets in the Pin Mux Utility is the best way to insure you are using one of the valid IO Sets supported on AM335x.

    You can deselect unused functions from one of the valid IO Sets without causing any problems, but you can not add them as you suggested with your comment  “select GPMC_CLK_MUX1 instead of GPMC_CSN1”.  The AM335x allows the GPMC_CLK signal to be multiplexed to the GPMC_CSN1 pin, but it is not one of the supported IO Sets.

    You can continue to select other interfaces, but you need to make sure the pin multiplexing options chosen for these interfaces are based on valid IO Sets.

    Several of the interfaces you mentioned are connected to dedicated pins.  RTC, ADC, EMIF, OSC0, and OSC1_RTC signals are connected to dedicated pins while most of the USB0, USB1, DEBUGSS signals are connected to dedicated pins.

     

    Regards,

    Paul

  • 0 in reply to peaves
    Intellectual 365 points

    Thanks Paul,

    In summary: after selecting an I/O Set, only "deselect" is possible, changes in the organization of the I/O set are not allowed.

    Deselected pins can be used further by other peripherals in their own I/O sets. Am I right ?

    As a suggestion, the PinMux utility should mark these pin changes as I/O set violation (orange), not as I/O subset (yellow).

    There is no warning when changing from one function to another.

    Marcelo

  • 0 in reply to Marcelo Barros
    TI__Guru 62855 points

    Yes, that is correct.

    I will pass along your suggestions to the person that developed the Pin Mux Utility.

    I would like to correct one of my previous comments.  I said the GPMC_CLK signal multiplexed to the GPMC_CSN1 pin was not an option in any of the supported IO Sets.  That is not true.  For example, if you had selected GPMC IO Set 25 rather than GPMC IO Set 26 it would multiplex the GPMC_CLK signal to the GPMC_CSN1 pin.

     

    Regards,

    Paul

  • 0 in reply to peaves
    TI__Expert 6735 points

    Paul:

    I am not sure of the meaning of your suggestion.   Signals can be deselected from an IO Set (IO Set subset).

    However, when a signal is added after selecting an IO Set, you may have a combination of signals that are

    not allowed by any IO Set (IO Set Violation).

    Regards,

    Michael T

  • 0 in reply to Michael T
    Intellectual 365 points

    Hi Michael

    I will try to make it clear. For example, consider I/O set 26 for GPMC. In this set, CPMC_CSN1 is used. However, in other I/O sets, this signal is deselected and this pin is used as GPMC_CLK_MUX1 (other possible function for this pin).

    When you select the I/O set 26 and change this pin, turning CPMC_CSN1 off and turning GPMC_CLK_MUX1 on, do we have an I/O Violation or not ? Pin Mux does not report this action as I/O Set Violation (all green) but, as written before in this thread, such action is not valid (or not only fully tested by TI?).

    Thanks you!

    Marcelo

  • 0 in reply to Marcelo Barros
    TI__Expert 6735 points

    Marcelo:

    What you have specified is supported.  It is a subset of IO Sets 21,21 &23.

    Regards,

    Michael

     

  • 0 in reply to Michael T
    TI__Guru 62855 points

     I just spoke to Michael and he explained how the Pin Mux Utility checks to see if selected signals of a peripheral are part of a valid IO set.

    When viewing selected signals of a peripheral via the respective Interface View window, the signals that are part of that peripheral are shown with bold text.  If you select a new signal by double clicking on the bold signal name the tools checks all selected signals to see if they are a subset of any valid IO Set(s).  If so, the valid IO Set(s) which contain this subset will be listed along the top of the window.  If not, it will say IO Set Violation!

    Caution: Do not add signals that are not part of the peripheral represented in the Interface View window by selecting non-bold signal names because these will not be flagged as an IO Set Violation. 

    I hope this helps when selecting the best combination of AM335x signals for you application.

     

    Regards,

    Paul 

  • 0 in reply to peaves
    Intellectual 365 points

    I found a problem in this design (two RMII, booting from NAND) related to board initialization.

    When booting from NAND, the WAIT0 signal should be used, as stated in the manual  (page 4547):

    "WAIT is monitored on GPMC_WAIT0"

    However, WAIT0 could no be used since it conflicts with RMII2_CRS_DV. As the boot code is a ROM code and can not be changed, I would like to know if we have any alternative to solve this issue. Unfortunately I can not boot from MMC.

    I was thinking about changing the source code of SPL (Second Program Loader), including some external glue logic to exchange WAIT0 and WAIT1lines  for NAND and doing a proper routing of RMII2_CRS_DV line. This way it would be possible to use a GPIO to exchange these signals after loading SPL into internal RAM, making NAND available through WAIT1 and enabling full RMII lines for the second ethernet. So u-boot and linux could boot using the pin mux setup discussed in this thread.

    Do you believe that this approach is feasible?

  • 0 in reply to Marcelo Barros
    Intellectual 365 points

    This question is answered in "AM335x ARM Cortex-A8 Microprocessors (MPUs) Silicon Revision 1.0, Silicon Errata", section 3.1.4. The revised pin mux is attached.1070.Final_AM335x_MMC_3UARTs.dat

    The AM335x device multiplexes the GPMC_WAIT0, GMII2_CRS, and RMII2_CRS_DV signals on the
    same terminal. This causes a problem when the system must support NAND boot while a MII or RMII
    Ethernet PHY is connected to port 2 of the Ethernet media access controller/switch (CPSW). The
    GPMC_WAIT0 signal is required for NAND boot. The GMII2_CRS or RMII2_CRS_DV signal is required by
    the respective MII or RMII Ethernet PHY and the only pin multiplexing option for these signals is
    GMPC_WAIT0.


    In this case, there are two sources that need to be connected to the GPMC_WAIT0 terminal. The NAND
    READY/BUSY output must source the GPMC_WAIT0 terminal during NAND boot and the MII CRS or
    RMII CRS_DV output must source the GPMC_WAIT0 terminal when the application software is using port
    2 of the CPSW. Therefore, a GPIO-controlled external 2-to-1 multiplexer must be implemented in the
    system to select between the two sources. The GPIO selected to control the 2-to-1 multiplexer needs to
    have an internal and/or external resistor that selects the NAND READY/BUSY output as soon as power is
    applied and remains in that state until the application software initializes the CPSW.
    The TI TS5A3157 SPDT analog switch is an example device that can be used as a 2-to-1 multiplexer.
    This device inserts minimum propagation delay to the signal path since it is an analog switch. The
    propagation delay inserted by the 2-to-1 multiplexer must be analyzed to confirm it does not cause timing
    violations for the respective interface.


    The NAND, Ethernet PHY, AM335x VDDSHV1, AM335x VDDSHV3 (when using the ZCZ package), and
    2-to-1 multiplexer I/O power supply domains may need to operate at the same voltage since they share
    common signals.