• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1190 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.

Original question:

AM2634-Q1: Autosar : GPIO Interrupt config feature Support

AM2634-Q1: GPIO Group and core mapping concept clarificaiton

Ashish Sebastian
Prodigy 225 points
Part Number: AM2634-Q1
Other Parts Discussed in Thread: SYSCONFIG, ASH

Hi Team,

I have some confusions related to the mapping of the GPIO modules and groups. Based on the references from the RM here is my understanding. 

  • There are 144 GPIO port pins available for IO processing. Each are interrupt capable
  • These 144 pins are grouped into 9 groups (A-I) as in the MCAL Port config. These groups are also referred to as Banks in the RM.
  • There are 4 GPIO modules GPIO0 - GPIO3
    • Each of the modules are mapped to the corresponding cores Core 0 - Core3
  • Each GPIO modules have configurations registers related to all 144 pins, as grouped in banks

Queries:

  • Are there 144 (pins) * 4 (GPIO modules) = 576 pin configurations possible?
  • Which pins/groups/banks are mapped to which core?
  • There are 2 concepts for INT routing related to the GPIO pints
    • GPIO_XBAR_INTRTR0 (Interrupt Router)
    • INPUTXBAR (configuration seen in MCU Autosar module)
      • Which of the above 2 concepts needs to be used to handle GPI input interrupt in specific port pins.
  • Would need some clarification on the usage of bank interrupts as we notice that each core can handle only 4 GPIO interrupts (142 - 145) in the VIM related to that core.
  • 0
    TI__Genius 16272 points

    Hi Ashish,

    I will get back to you soon with answers to all the above queries.

    Regards,

    Shaunak

  • 0
    TI__Intellectual 2006 points

    Hi Ashish,

    Ashish Sebastian said:
    Are there 144 (pins) * 4 (GPIO modules) = 576 pin configurations possible?

    Technically, one can configure given physical GPIO pin for one GPIO bank. so at a time only one set of 144 configurations are possible.

    Ashish Sebastian said:
    Which pins/groups/banks are mapped to which core?

    There are 144 GPIO Pins but only one core can drive per pin based on its PinMux configurations. so these 144 GPO pins are resources that can be configured for each core exclusively. but all GPI may be read at all 4 GPIO banks i.e., by all 4 cores. 

    please refer to note in the 4.10 GPIO integration in TRM.

     

    Ashish Sebastian said:
    There are 2 concepts for INT routing related to the GPIO pints
    • GPIO_XBAR_INTRTR0 (Interrupt Router)
    • INPUTXBAR (configuration seen in MCU Autosar module)
      • Which of the above 2 concepts needs to be used to handle GPI input interrupt in specific port pins

    There are 2 concepts for INT routing related to GPI. 

    1. Direct GPIO_XBAR_INTRTR0 outputs. there are 16 outputs, 4 per each VIM. each output can select either given GPIO_MUX_x or a GPIO_BANK_INT as input.
      1. refer to 10.3.2.3 in TRM for Interrupt connections to VIM
    2. Indirect via SOC_TIMESYNCXBAR1, there are 5 GPIO_XBAR_INTRTR0 outputs that can be connected to SOC_TIMESYNC1. again there are 16 outputs from the SOC_TIMESYNCXBAR1 connected to VIMx, 4 per each VIM. 
      1. refer to table 12-9 for SOC_TIMESYNCXBAR1 connections to VIM.
    Ashish Sebastian said:
    Would need some clarification on the usage of bank interrupts as we notice that each core can handle only 4 GPIO interrupts (142 - 145) in the VIM related to that core.

    For Each GPIO peripheral (1 per core), the 144 GPI are grouped into 9 banks, each containing 16 pins. these Banks can generate INT based on any of the 16 GPI. these INT again, need to be routed through GPIO_XBAR_INTRTR0 to VIM or indirectly as mentioned above.

    refer to 13.1.1.4.3 GPIO Interrupt and Event Generation in TRM for more info.

    Thanks,

    Madhava 

  • 0 in reply to Mihira Madhava Bollapragada
    Prodigy 225 points

    Hello Madhava,

    Thanks yo so much for the quick response. I shall have a detailed look in 2 days as I am in the middle of some tests for a delivery tomorrow. If I would need more clarifications, after looking through your response; do you think we would be able to have a short call in 2 days please?

  • 0 in reply to Ashish Sebastian
    TI__Intellectual 2006 points

    Hi Ashish,

    Please post the queries that you would want to discuss in the call on this forum. We will try to get back on them.

  • 0 in reply to Mihira Madhava Bollapragada
    Prodigy 225 points

    Hello Madhava,

    I am currently working with the sdk example project 'gpio_input_interrupt_am263x-lp_r5fss0-0_nortos_ti-arm-clang'. And this is what I notice as per the code flow. 
     

    Just to let you know that i am trying to make it work in the Autosar MCAL env. I notice that the PWM_Init takes care of BINTEN, PIN_DIR and PIN_TRIG regs. So, I have configured the CAT2 ISR for VIM intr 142

    But my ISR does not hit. I suppose that the missing link would be the INT router mapping/configuration. But I do not see this mapping from the SDK example that I have mentioned earlier. 

    Do let me know what you think; that I am missing.

  • 0 in reply to Ashish Sebastian
    TI__Intellectual 2006 points

    Ashish, 

    Can you check the sysconfig generated code for the same example? There is a GPIO_XBAR_INTRTR configuration from this GPIO bank happening in the same example. Also, the example has been updated in the latest SDK (8.6). 

  • 0 in reply to Mihira Madhava Bollapragada
    Prodigy 225 points

    Hi Madhava,
    I did check the generated code and configured the INTRTR module as well; I can now see that the GPIO_XBAR_INTR_MUXCNTL register is also updated as per the sample example. 

    The sdk sample works fine. But in the Autosar environment; the ISR at the SW4 button press does not get triggered; if flashed after clearing all the registers. Strangely; what we also see is that if we flash the sdk example and then flash the Autosar SW (without clearing the register settings); the Autosar SW ISRs also get triggered.

    I have cross checked the GPIO0_BINTEN, GPIO0_DIR, GPIO0_SET_RIS_TRIG, GPIO0_CLR_RIS_TRIG, VIM_INTR_EN_SET_4 registers; and they look almost as per the values in the sdk example. I am a bit unclear if we would need to consider the VIM_PRIIRQ, VIM_IRQVEC registers as I see some differences but un able to interpret what is expected. 

    Is there any other registers; that I will need to monitor. It would be grateful; if we could try to have a short debug call.

  • 0 in reply to Ashish Sebastian
    Prodigy 225 points

    Hello Madhava,

    Any updates/suggestions from your side. Would it be possible for a short debug session please. I am not able to proceed further with the topic. 

  • 0 in reply to Ashish Sebastian
    TI__Intellectual 2006 points

    Hi Ashish, 

    The Issue seems to be in the ISR registration. However, I am not well versed with the ISR registration process in the AutoSAR environment. I have requested an expert on this subject to comment on/ help better. 

    thanks,

    Madhava

  • 0 in reply to Mihira Madhava Bollapragada
    Prodigy 225 points

    Hi Madhava,

    I had created a separate ticket for same topic to the Autosar team
    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1247776/am2634-q1-autosar-gpio-interrupt-config-feature-support?tisearch=e2e-sitesearch&keymatch=empel#

    Since the feature is not implemented on their side, I will need to integrate stuff from SDK to get the feature support in the Autosar environment. Not sure now, as to who could be able to review or come for a quick session. 

  • 0 in reply to Ashish Sebastian
    TI__Genius 12330 points

    Hi Ashish,

    Can you please clarify below queries?

    1) In AUTOSAR environment how are you doing GPIO configuration?Are you using Port and Dio Module?

    2) If not above, only interrupt registration is done in AUTOSAR and you are not able to get interrupt?

    Thanks And Regards,

    Sunil Kumar M S

  • 0 in reply to Sunil Kumar M S
    Prodigy 225 points

    1) In AUTOSAR environment how are you doing GPIO configuration? Are you using Port and Dio Module?

    Ash : Hi Sunil. Yes we are using the Port and DIO MCAL modules to configure this GPIO Pin. I see that after the Port_init is called the Bank interrupt and the PinDirection bits in the corresponding register related to the GPIO pins are updated. However the rising /falling edge trigger reg was not updated even if the configuration is done. So I had to use the SDK API to set this reg for the GPIO pin under test.

    2) If not above, only interrupt registration is done in AUTOSAR and you are not able to get interrupt?

    For the INT configuration there are 2 steps:

    * Set the INTRTR setting to route the INT to the VIM -> This I have done by using the API from sdk, as the configuration option is not available for this in MCU

    * Configure the OSISR for GPIO interrupt (142), as CAT2 ISR

  • 0 in reply to Ashish Sebastian
    Prodigy 225 points

    Initializing the PINMUX reg for GPIO123 from the Port config was needed to get the GPIO functional. To get 0x507 in the mux reg; we had to update 2 params in MCAL port module as in the screen shot below:

     But this config is not working for some other Pins (Gpio 26, used for LED blink).

    Need to check this further

  • +1 in reply to Ashish Sebastian
    TI__Genius 12330 points

    Hi Ashish,

    As we are debugging this thread over the call, I will update the status to waiting for customer.

    Thanks And Regards,

    Sunil Kumar M S

  • 0 in reply to Ashish Sebastian
    Prodigy 225 points

    The config seems to work for GPIO26 as well.SO closing the issue.