• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 203 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.

TMDS64EVM: How to set PADCONIG MUX values from PRU

Seth Appleman
Prodigy 230 points

Part Number: TMDS64EVM
Other Parts Discussed in Thread: SYSCONFIG

This is a continuation of previous thread which had a recent follow up question but may be lost in the ether: AM6422: How to configure PRU GPIO pins - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums . Some of the questions from the original post were answered but others got lost in the exchang.

Latest question:

I am writing C code for ICSSG1_PRU0, and trying to use the RGMII interface to write a simple Ethernet driver (I do not have the option of using the SDK code files for my application due to customer requirements). I am connected to the PRU through CCS XDS110 as described on the "Getting Started" guide for the TMDS64EVM. I need to configure the board pins such that the RGMII interface is enabled.

In the PRU code, I am setting ICSSG_GPCFG0_REG.PR1_PRU0_GP_MUX_SEL = 2 (MII mode). I have PRU code that is also attempting to set the PADCONFIG Mux values for PADCONFIG46, PADCONFIG47, etc to Mux Mode 2 to engage PRG1_RGMII1_R* and PRG1_RGMII1_T* function on those select pins. 

1) Am I able to write to the PADCONFIG registers from the PRU code itself?

2) When connected to the PRU for debugging, do I need to write to the pin PADCONFG registers to engage the RGMII function on those pins or is the PRU writing 2 to ICSSG_GPCFG0_REG.PR1_PRU0_GP_MUX_SEL enough?

3) If the PRU can not write to PADCONFIG registers, but the PADCONFIG registers do need to be written to, what other options do I have when connected to and debugging from the PRU, since there is no code running on the Arm core?

 

  • 0
    TI__Guru** 110030 points

    Hello Seth,

    Yes, the PADCONFIG registers can be configured from any core that has the software to modify them. So they can be configured from the ARM core, but also the PRU core itself. If writing settings from multiple cores, take care that all the hardware settings are aligned across every software instance.

    Yes, you need to make sure your PADCONFIG settings are correct 

    The PRU's internal MUX_SEL picks which signals get sent out of the PRU subsystem, into the SoC itself. But there is a second signal multiplexer at the pin itself which must ALSO be muxed properly to select the PRU signal instead of one of the other processor signals attached to the pin multiplexer (i.e., the "pin mux").

    Examples of setting PADCONFIG registers from PRU 

    PRU has read/write access to any part of the system accessible with an SoC-level address (assuming you haven't set up firewalls to block access from that core), including the PADCONFIG registers.

    These OpenPRU examples all configure the pinmux settings from the PRU cores:
    https://github.com/TexasInstruments/open-pru

    custom_frequency_generator, fir, logic_scope, multicore_scheduler

    Note the kick registers that protect the PADCONFIG settings from accidental modification. Make sure that you are using those registers consistently across all your code - for example, you don't want the ARM to rely on the kick registers being unlocked, and then the PRU cores locking them after modifying, leading to unexpected behavior if the ARM tries and fails to adjust the settings later in runtime.

    CCS GEL files? 

    I have not done this myself on AM64x, but on older processors we could also tell CCS to apply pinmux settings with GEL file scripts (e.g., see https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/11_02_08_02/exports/docs/common/PRU-ICSS/PRU-Hands-on-Labs.html ). So this might be another option during CCS debug if the ARM core is not configuring the pinmux settings yet.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 110030 points

    For future readers, you can find more about basic concepts for sharing system resources in the AM64x multicore academy > memory & peripherals section:
    https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AJa64F6ctzZNbb.TYx4mCA__AM64-ACADEMY__WI1KRXP__LATEST

    Some of the information does not apply to Seth's usecase, since he is not programming the A53 core with Linux. But the basic concepts of "all cores must agree on resource usage and avoid conflicting with each other's settings" is extremely important, especially if he won't be using tools like SysConfig to check for resource conflicts between his RTOS / bare metal software instances.

    Regards,

    Nick