Forums

Peter,

- I guess that you are using the PINMUX utility (PINMUXTOOL) to find out what pin multiplexing options are possible:
 http://www.ti.com/product/am3356

It seems that you are correct. For U17 pin the GPMC WP signal for NAND and the GMII2 RXERR signal are conflicting. I am double checking (you will get some comment on the E2E) on this but I think there are not much ways to workarround this.
Still WP seems to be used to make the NAND permanently writable so it might not be a key function. You could use a GPIO instead if it is truly needed.
For example on AM18xx we did not have this pin on the EMIF/GPMC and we advised to use a GPIO and some SW to implement this.

- There are some consideration to take into account for NAND, especially if you want to boot from NAND.

The following page will give some useful information. It relates to older AM3xxx devices but most of it applies to AM335x devices:
http://processors.wiki.ti.com/index.php/Raw_NAND_ECC
NAND device can become end of life quite quickly and it can be difficult to find a compatible replacement (one of the reason being the evolution in the ECC support over time). OneNAND and managed NAND do have built in ECC so you do not suffer of this ECC compatibility problem.  Still note that on AM335x the ECC support improved compared to previous AM3xxx generation.

Note as well that for NAND boot some assumptions are made (like device ID, page organization, ..etc) so make sure to double check section 26.1.7.2.5 of the AM335x TRM - SPRUH73B.

Hope it helps.

Anthony

Hi Anthony,

Can you confirm if there is any way around the conflicts on T17 (GPMC_WAIT0/GMMI2_CRS) and U17 (GPMC_WPN/GMII2_RXER) to enable NAND Flash and GMII2 to be used at the same time (ZCZ package)?

We are planning to use GMMI2 as a EtherCat Master interface which will not require GMMI2_CRS.  Is it safe to allocate T17 to be GPMC_WAIT0 without affecting the functionality of the GMII2 peripheral (if CRS is not required)?

Also, as you mentioned in the earlier post, GPMC_WPN could be controlled by a separate GPIO and U17 assigned to GMII2_RXER.  Could you see any issues with this?  and in particular when booting from NAND flash?

Kind Regards

Mark Norman

The AM335x Silicon Errata provides a description of the GPMC_WAIT0 pin multiplexing limitation and an example hardware workaround.  This solution could also be used for the GPMC_WPN signal.

The hardware workaround example described in the AM335x Silicon Errata assumes the NAND WAIT input is only used while AM335x is booted from NAND.  If the NAND WAIT input is required after AM335x is booted, the hardware workaround may need to be expanded to include a connection to the GPMC_WAIT1 signal after AM335x is booted.

Regards,
Paul

Hi Paul,

Thank you for your response and link to the Silicon errata.

Currently we are looking to use NAND and GMII2 at the same time making the multiplexing option a bit tricky.  We are only planning to use the GMII2 as an EtherCat Master interface which does not require CRS (presumably because it only operates in full duplex mode).  The technical reference manual (spruh73d) specifies that GMII2_CRS should be held low in full duplex operation.  Would it be safe to set the T17 MUX to be GPMC_WAIT0?  What impact would this have on the GMII2 module and how it interprets the value of GMII2_CRS?

Kind Regards

Mark Norman

The pin multiplexing logic will source a low logic level to the internal CRS signal when the IO associated with terminal T17 is not configured for pin multiplexing mode 1.  Therefore, the Mac will always see a low logic level on the CRS input if you select pin multiplexing mode 0.

The IEEE Standard 802.3 defines the following requirements for CRS.

22.2.2.9 CRS (carrier sense)

CRS shall be asserted by the PHY when either the transmit or receive medium is nonidle. CRS shall be deasserted by the PHY when both the transmit and receive media are idle. The PHY shall ensure that CRS remains asserted throughout the duration of a collision condition.

CRS is not required to transition synchronously with respect to either the TX_CLK or the RX_CLK.

The behavior of the CRS signal is unspecified when the duplex mode bit 0.8 in the control register is set to a logic one, as described in 22.2.4.1.8, or when the Auto-Negotiation process selects a full duplex mode of operation.

The MAC may ignore the state of CRS when configured to full-duplex based on this definition of CRS.  However, I would like to confirm this with the MAC designer.  This may take a few days to get an answer, but will reply to this post as soon as I get an answer.

Regards,
Paul

The MAC designer has confirmed the state of the CRS input is ignored in full-duplex mode. 

Regards,
Paul

Hi Paul,

Thanks for following this up.

Regards

Mark

if i want to use two ethernet and boot from the NANDFLASH,can the PRU_MII0 and PRU_MII1 be used as the ICE board designed? by the way,what is the difference between the PRU_MII and the GEMAC_CPSW/MII?

thanks!