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
From my point of view, the consequences are:
My question is: given the limitations, is this design valid? Is it really possible to deselect part of the bus?
Thanks a lotMarcelo 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.
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
Hello Michael
I did it in my post, see "PinMux Setup" 6786.2xRMII_GPMC16Ext_AM335x.zip
(.dat is inside a .zip file)
Thanks
Marcelo
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.
Paul
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.
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.
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).
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!
What you have specified is supported. It is a subset of IO Sets 21,21 &23.
Michael
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.
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?
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 thesame terminal. This causes a problem when the system must support NAND boot while a MII or RMIIEthernet PHY is connected to port 2 of the Ethernet media access controller/switch (CPSW). TheGPMC_WAIT0 signal is required for NAND boot. The GMII2_CRS or RMII2_CRS_DV signal is required bythe respective MII or RMII Ethernet PHY and the only pin multiplexing option for these signals isGMPC_WAIT0.
In this case, there are two sources that need to be connected to the GPMC_WAIT0 terminal. The NANDREADY/BUSY output must source the GPMC_WAIT0 terminal during NAND boot and the MII CRS orRMII CRS_DV output must source the GPMC_WAIT0 terminal when the application software is using port2 of the CPSW. Therefore, a GPIO-controlled external 2-to-1 multiplexer must be implemented in thesystem to select between the two sources. The GPIO selected to control the 2-to-1 multiplexer needs tohave an internal and/or external resistor that selects the NAND READY/BUSY output as soon as power isapplied 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. Thepropagation delay inserted by the 2-to-1 multiplexer must be analyzed to confirm it does not cause timingviolations for the respective interface.
The NAND, Ethernet PHY, AM335x VDDSHV1, AM335x VDDSHV3 (when using the ZCZ package), and2-to-1 multiplexer I/O power supply domains may need to operate at the same voltage since they sharecommon signals.