• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 459 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.

AM2432: SYSCONFIG Pins

Mari Tsunoda
Expert 5726 points
Part Number: AM2432
Other Parts Discussed in Thread: SYSCONFIG

Hi Team,

My customer has a few questions with regards to using the sysconfig tool. 

1. What are the GPMC_CLKLB and MMC1_CLKLB signals? It does not have much relevant documentation in the TRM nor the datasheet and does not seem to connect to any of the pins, but is shown in the tool.

2. When using the sysconfig tool, in the 'Welcome To SysConfig' page, is it the correct procedure to select a 'software product' always? Unless they do not select anything (as below), they cannot see the Power Domains tab (the little icons) on the left-hand side, and the files pinmux_data.c and PinmuxConfigSummary.csv are not generated. Why is it that these files are not generated, and why does the Power Domains tab appear/disappear? Also, how do they know which 'software product' and 'context' to choose?

3. Is the power domain tab not reflected in the code? For example, when using GPMC0_A2(W7) VDDSHV2 and GPMC0_AD4(U18) VDDSHV3 , they set VDDSHV2=1.8V and VDDSHV3=3.3V, but they get a warning.

Best regards,

Mari Tsunoda

  • 0
    TI__Mastermind 23043 points

    Hey Mari,

    1) The GPMC_CLKLB and MMC1_CLKLB signals are the on-die peripheral clock signals that are "looped back" from the associated _CLK signal/pin internal to the package. PADCONFIG CTRLMMR registers still exist for these signals, but there is no associated ball on the device. These loopback signals are used to ensure proper time enclosure restraints are met during peripheral operation.

    2a) If a customer has an evm/hw and wants to start developing software, they should use MCU+SDK (Software Product) for their specific device. If the customer is interested in exploring pinmux options and system level use cases (# of peripheral/interface instances) then they can use the alternate raw pinmux view.

    2b) The Power Domains tab is a feature of the raw pinmux view to enable you to set contrasting/invalid configurations and receive a warning. These invalid setups are disabled by default when using the MCU+SDK Software Product as it will only provide fully valid configurations.

    2c) The MCU+SDK doesn't require the pinmux_data.c file and the PinmuxConfigSummary.csv was provided as an easy review option for pre-silicon system level use case development. While we could look at also providing the csv as an output of the MCU+SDK Software Product generated files, it is more useful to use the full .syscfg file itself as a way to review and validate configuration.

    2d) Customer should always choose the Software Product for their associated device.

    AM243x LaunchPad = MCU+SDK for AM243x

    AM243x GPEVM = MCU+SDK for AM243x

    AM263x LaunchPad = MCU+SDK for AM263x

    AM263x Control Card = MCU+SDK for AM263x

    etc....

    If they are wanting to use the raw pinmux/Power Domains view, then they should select the appropriate device from the dropdown list.

    3) As mentioned in answer 2b, these error/warning generating scenarios are avoided by proper configuration expectations made for the Software Products. In other words, while using a software product, you will not be given the ability to choose any configuration options that would result in these voltage conflicts.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Expert 5726 points

    Hi Zackary,

    Thanks for the quick responses.

    I will post their follow-up questions below for each question.

    1) If the CLKLB signals don't have associated balls, what effect would it have if they were to uncheck the box for CLKLB in SysConfig? (ie. pin conflicts and configuration file code)

    2)

    Fleenor said:
    While we could look at also providing the csv as an output of the MCU+SDK Software Product generated files, it is more useful to use the full .syscfg file itself as a way to review and validate configuration.

    So does the .syscfg file, the pinmux_data.c file, and the csv output file provide the same information? Also, then is the recommendation for the user to just look at the .syscfg file instead of the other files mentioned?

    Best regards,

    Mari

  • 0 in reply to Mari Tsunoda
    TI__Mastermind 23043 points

    Hey Mari,

    All good questions.

    1) Yes the CLKLB signals don't have associated balls, but the pad still exists and is connected internal to the package. Use of the CLKLB signals is system/interface dependent. If the CLKLB signals are left unchecked then the associated PADCONFIG registers will be be set to the default state upon reset and remained unchanged during boot/active phases.

    2) The .syscfg file is much more comprehensive and describes multiple aspects/details of the overall system configuration, including the subset of pinmux configuration details. The files are all just different expressions (generated files) of the configuration data entered into they GUI and saved as .syscfg source file. So yes, the recommendation would be to use the .syscfg file as the critical data source from which all other files can be comprehended/generated.

    Best Regards,

    Zackary Fleenor

  • 0 in reply to Fleenor
    TI__Expert 5726 points

    Hi Zackary,

    Thanks for your reply.

    1) Is there any documentation relevant to the CLKLB signals I can point the customer to? I was looking at the datasheet and TRM, and it doesn't seem to have a lot of information. Also would you be able to elaborate on this? I'm still a little confused as to why it's looped back.

    Fleenor said:
    The GPMC_CLKLB and MMC1_CLKLB signals are the on-die peripheral clock signals that are "looped back" from the associated _CLK signal/pin internal to the package.

    2) Thanks for the clarification. Will let them know.

    Best regards,
    Mari

  • 0 in reply to Fleenor
    TI__Expert 5726 points

    Hi Zackary,

    Sorry for the repeated questions about the LBCLK. Is the clock loopback from OSPI/QSPI the same the clock loopback in eMMC1 and GPMC?

    Best regards,

    Mari

  • 0 in reply to Mari Tsunoda
    TI__Mastermind 23043 points

    No problem at all. Each interface has it's own dedicated loopback clock. I will go ahead and close this thread, please start a new one with any additional questions regarding loopback clock.

    Best Regards,

    Zack

  • 0 in reply to Fleenor
    TI__Expert 5726 points

    Hi Zack,

    Thanks for your support on this thread.

    I'll be meeting with the customer soon so I will let you know if there are any follow-up questions regarding non-loopback clock related questions on here if that's ok. Please let me know if it's better to make a new thread for that too.

    Also, I've made a new post for the loopback clock questions per your advice. 

    Best regards,

    Mari