• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 432 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.

AM2434: Unassigned PAD Configuration Registers

Daisuke Maeda
Guru 20205 points
Part Number: AM2434

The following PAD Configuration Registers are unassigned in "Table 6-1. Pin Attributes (ALV, ALX Packages)" on the datasheet, but each of them is described in the notes for "Table 6-44. GPMC0 Signal Descriptions" or "Table 6-62. MMC1 Signal Descriptions".

PADMMR_PADCONFIG32 000F 4080h
PADMMR_PADCONFIG164 000F 4290h

For GPMC0_CLK:
"The RXACTIVE bit of the CTRLMMR_PADCONFIG32 register must be set to 0x1 and the TX_DIS bit of the CTRLMMR_PADCONFIG32 register must be reset to 0x0 when GPMC0 is operating in synchronous mode."

For MMC1_CLK:
"For MMC1_CLK signal to work properly, the RXACTIVE bit of the CTRLMMR_PADCONFIG164 register must remain in its default state of 0x1 for retiming purposes."

In Table 6-1, PADCONFIG31 is assigned for GPMC0_CLK and PADCONFIG163 for MMC1_CLK.

Must each of PADCONFIG32 and PADCONFIG164 be set as described in the notes for Table 6-44 or Table 6-62?

If not, can each be left at its default (reset value)?

Best regards,

Daisuke

  • 0
    Guru 20205 points

    Dear TI support team,

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    Guru 20205 points

    Dear TI support team,

    Is PADCONFIG31 used instead of PADCONFIG32 for GPMC0_CLK?

    Is the note for "Table 6-44. GPMC0 Signal Descriptions" incorrect?

    "The RXACTIVE bit of the CTRLMMR_PADCONFIG32 register must be set to 0x1 and the TX_DIS bit of the CTRLMMR_PADCONFIG32 register must be reset to 0x0 when GPMC0 is operating in synchronous mode."

    Is PADCONFIG163 used instead of PADCONFIG164 for MMC1_CLK?

    Is the note for "Table 6-62. MMC1 Signal Descriptions" incorrect?

    "For MMC1_CLK signal to work properly, the RXACTIVE bit of the CTRLMMR_PADCONFIG164 register must remain in its default state of 0x1 for retiming purposes."

    Are PADCONFIG32 and PADCONFIG164 not used for any pins?
    If so, must each of PADCONFIG32 and PADCONFIG164 be left at its default (reset value)?

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Expert 7630 points

    Hi Daisuke-san,

    Our expert is OOO so please expect a slight delay on answering this question. I will reach out to him to bring this thread up to his attention.

    Best,

    Daniel 

  • +1 in reply to Daisuke Maeda
    TI__Mastermind 22953 points

    Hello Daisuke,

    GPMC0 has two clock signals associated with it, GPMC0_CLK (PADCONFIG31) and GPMC_CLKLB (PADCONFIG32).

    In similar fashion, MMC1 also has two clock signals associated with it, MMC1_CLK (PADCONFIG163) and MMC1_CLKLB (PADCONFIG164).

    The second signal here is a Clock Loopback signal for I/O delay compensation for greater timing accuracy. The CLKLB signals are connected within the package and are not routed out to a package ball.

    Even though the loopback signals are internal only and not routed out, they must be configured correctly for the main clock of the peripheral interface to work correctly.

    When GPMC0 is operating in "Synchronous Mode" the PADCONFIG32 register must be configured as described in the footnote for proper functionality. The same is true for the PADCONFIG164 in relation to MMC1 peripheral timing. These notes exists because SR1.0 silicon did not correctly set these bits by default after reset. The default reset values were resolved in SR2.0, but the notes still remains true.

    Thus, if you are using SR1.0, these bits should be manually configured as specified, but if you are using SR2.0, these values can remain in the default state after reset.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    Guru 20205 points

    Hi Zackary-san,

    Thank you for your detailed response.

    Best regards,

    Daisuke