• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 356 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.

AM623: AM6232 GPIO Configuration

Jamie Hofer
Prodigy 190 points
Part Number: AM623
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello,

My customer had the following question about configuring the AM6232 GPIO pins using sysconfig:

Had a qn on the GPIO configuration of the chip. I'm using the syscfg tool to do the pin mapping for the chip and am seeing that there's an error when allocating pins on the same GPIO class (GPIO0 and GPIO1). Looks like the error I am getting points to the fact that all GPIOs in the same class need to have the same voltage IO as opposed to being referenced to their rail. 

 

So for eg. below i have GPIO0_3 (powered by VDDSHV1) set at a 3.3V IO should be referenced to VDDSHV1 but since alot of the GPIO0 pins are set to 1.8V IO this error appears. Should i suppress errors like this if they are connected to the correct power rail even though they are part of the same IO class (GPIO0) or is it true that each IO class needs to just have one voltage level

  • 0
    TI__Guru** 101760 points

    Hello Jamie,

    The way that I understand it, GPIO0 is one GPIO module, and GPIO1 is a different GPIO module. So it would make sense to me that a GPIO module would only have a single power rail (i.e., all signals connected to the same GPIO module need to be at the same max voltage). However, I am not a GPIO hardware expert.

    I have assigned your thread to one of our team members. Please note that this is a holiday week in India. Feel free to ping the thread if you do not get a response within a few business days.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Prodigy 190 points

    Hey Nick,

    Are you referring to the text above "name" where it says GPIO1? I thought in sysconfig that those are more or less irrelevant because you have the option to select "use peripheral". 

    Jamie

  • 0 in reply to Jamie Hofer
    TI__Guru** 101760 points

    When a processor core is reading or writing to a GPIO pin, it is NOT directly accessing the pin itself.

    Instead, the processor core reads or writes to a bunch of circuits that we call a GPIO module. This GPIO module then does the actual reading and writing of the pin. From the datasheet, you can see that there are only 3 different GPIO modules on the AM62x:

    You also have to keep these GPIO modules in mind when allocating GPIO signals between your processor cores. A single GPIO module can be controlled by Linux A53, OR one of the MCU+ cores. You cannot have both Linux and an MCU+ core controlling the same GPIO module.

    Regards,

    Nick

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

    Hello Jamie, 

    Signals are grouped by function/domain, not power domain. It is therefore possible to encounter voltage conflict warnings with some peripherals. This is a warning to highlight a difference between the preferred voltage and the actual pin voltage so you can take any necessary action should there be a real conflict.  Most useful when grouping GPIO signals from different voltage domains. 

    This is because the current tool configuration only allows one preferred voltage per peripheral. Where peripherals that include pins with different voltages, a warning will be present.

    Please refer to the pin attributes section of the data sheet to understand the IO supply for IO groups. All the IOs within an IO group is expected to be connected to the same supply that is connected to IO supply for the IO group. 

    Regards,

    Sreenivasa

  • 0 in reply to Kallikuppa Sreenivasa
    TI__Prodigy 190 points

    Hey Kallikuppa,

    If it highlights a conflict when the actual and preferred voltage differ, why would it highlight a conflict with preferred voltage set to "any"?

    See attached sysconfig file. The error in question is GPIO0_3 voltage conflict 

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/1045/4237.Home-Controller-2-Pin-Map.syscfg

  • 0 in reply to Jamie Hofer
    TI__Guru**** 192689 points

    Hello Jamie, 

    Thank you.

    Let me check with the expert.

    Regards,

    Sreenivasa

  • +1 in reply to Kallikuppa Sreenivasa
    TI__Mastermind 28125 points

    Jamie

    Jamie Hofer said:

    If it highlights a conflict when the actual and preferred voltage differ, why would it highlight a conflict with preferred voltage set to "any"?

    See attached sysconfig file. The error in question is GPIO0_3 voltage conflict 

    The Preferred Voltage is set for the complete peripheral rather than per pin, so it is possible to encounter warnings. The GPIO0 signals are powered by several VDDSHV power domains.

    Your scenario:

    Pin Power  Setting
    GPIO0_3 VDDSHV1 3.3V
    GPIO0_37 VDDSHV3 1.8V
    GPIO0_38 VDDSHV3 1.8V
    GPIO0_52 VDDSHV3 1.8V
    GPIO0_56 VDDSHV3 1.8V
    GPIO0_57 VDDSHV3 1.8V
    GPIO0_61 VDDSHV3 1.8V
    GPIO0_63 VDDSHV3 1.8V
    GPIO0_77 VDDSHV2 3.3V
    GPIO0_91 VDDSHV2 3.3V

    Since the tool can chose the Voltage Preference (Any), it has selected 1.8V  as that  results in the least voltage conflicts (3).  If the Preferred Voltage was set to 3.3v then there would be 7 conflict warnings.

    The warnings are just that, warnings.   They are there to highlight the conflict so that, if needed, design accommodations can be made. 

    --Paul 

  • 0 in reply to PaulM
    TI__Prodigy 190 points

    Hey Paul,

    Thanks for the clarification! So I assume the GPIO0_x pins on VDDSHV(1/2) are at 3.3v because those power domains are set by the GPIO1 module where the preferred voltage is set to 3.3v?

    Regards,

    Jamie

  • 0 in reply to Jamie Hofer
    TI__Guru**** 192689 points

    Hello Jamie,

    Thank you.

    Your understanding is correct.

    Regards,

    Sreenivasa