• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 502 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.

TDA4VH-Q1: Problem with configuring multiple GPIO interrupts

Mikolaj P
Prodigy 30 points

Part Number: TDA4VH-Q1

Hey. I'm trying to configure four GPIO interrupts on falling edges from the MCU domain. Three of them work in hardware, but the last one doesn't trigger a callback. So I swapped the interrupt configuration order in the GPIO_PinConfig gpioPinConfigs[] array (I only changed that one), and the fourth one started working, while the first one stopped. Is there a define somewhere in the pdk_j784s4_10_01_00_25 that defines the maximum number of GPIO interrupts? 

  • 0
    TI__Mastermind 22680 points

    Hi,

    Thanks for this information. There is no define for a maximum number of GPIO interrupts enabled. There are no software restrictions on this.

    I have ran some tests within the GPIO driver and observed the same issue with registering interrupts. I will raise this bug to the development team and focus on implementing a fix in the SDK.

    Could you please provide which GPIO pins you are using?

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 30 points

    Thank you for your response. 
    I am using GPIO33, GPIO34, GPIO35, GPIO27. 

  • 0 in reply to Mikolaj P
    TI__Mastermind 22680 points

    Hi Mikolaj,

    Let me run some tests and get back to you on this.

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    TI__Mastermind 22680 points

    Hi Mikolaj,

    The main issue arises from the following if condition in GPIO_setConfig_v0() function within drv/gpio/src/v0/GPIO_v0.c:

    if ((portHwiCreatedBitMask & gpioPortIntBitMask) == 0U) {

    I believe this is preventing the GPIO interrupt registration for all the GPIO pins to occur. Could you please test commenting this out and see if you can register interrupts on all the GPIO?

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 30 points
    Thank you for your reply.
    I tested it and it works on my hardware. I'm concerned about this change because I'm unsure how it might impact other functionalities...
  • 0 in reply to Mikolaj P
    TI__Mastermind 22680 points

    Hi Mikolaj,

    Thanks for testing this and confirming the root cause of the issue. 

    Mikolaj P said:
    I'm concerned about this change because I'm unsure how it might impact other functionalities...

    Yes you are correct, this is not an official patch for this GPIO bug within the driver. This has been reported to the development team and they are working on providing a fix within the SDK release.

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 30 points

    Hello Neehar, 

    We've noticed that your tip doesn't solve the problem. After adding your tip to the code, the interrupts on the other MCU stopped working.
    Try the following configuration:
    GPIO33 MAIN_GPIO_PORT MCU2_1
    GPIO34 MAIN_GPIO_PORT MCU2_1
    GPIO35 MAIN_GPIO_PORT MCU2_0
    GPIO27 MAIN_GPIO_PORT MCU2_0

    and the interrupts on core MCU2_1 have stopped executing.

    Thanks,
    Mikolaj

  • 0 in reply to Mikolaj P
    TI__Mastermind 22680 points

    Hi Mikolaj,

    This will not fully resolve the issue and the development team is analyzing the issue to have a fix in the SDK release.

    So your current status is the GPIO on MCU2_0 have no issues with interrupts but GPIO on MCU2_1 do not work? Does the interrupt registration pass such as the return value of GPIO_socConfigIntrPath()?

    Mikolaj P said:
    Try the following configuration:
    GPIO33 MAIN_GPIO_PORT MCU2_1
    GPIO34 MAIN_GPIO_PORT MCU2_1
    GPIO35 MAIN_GPIO_PORT MCU2_0
    GPIO27 MAIN_GPIO_PORT MCU2_0

    Additionally, I would not recommend using this GPIO configuration as you have GPIO in the same bank generating interrupts on different cores. Since our driver uses banked interrupts, it can cause false interrupts to occur on MCU2_0 or MCU2_1.

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 30 points

    Hello Neehar, 
    Exactly, the current status is GPIO on the MCU2_0 working and we are observing executed callbacks but on the MCU2_1 do not work. I will check the returned value later when I find time.

  • 0 in reply to Mikolaj P
    TI__Mastermind 22680 points

    Hi Mikolaj,

    Thanks, I will wait to hear back on the return value of GPIO_socConfigIntrPath().

    The MCU2_1 GPIO had no issue previously? Since these are on different cores, I do not expect to have any conflicts in interrupt registration as each core has specific interrupt lines allocated. It will depend on the values used within GPIO_socConfigIntrPath().

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    TI__Mastermind 22680 points

    Hi Mikolaj,

    Following up, is this issue still open? 

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 30 points

    Hello Neehar,
    The issue is still open, but I have not checked register values using the debugger yet 

  • 0 in reply to Mikolaj P
    TI__Mastermind 22680 points

    Hi Mikolaj,

    Thanks for the update, I will wait to hear back on the return value of GPIO_socConfigIntrPath().

    Thanks,

    Neehar

  • 0 in reply to Neehar Sawant
    Prodigy 30 points

    Hello Neehar,

    GPIO_socConfigIntrPath() returns only 0 values on both cores (mcu2_0 and mcu2_1)

    Sorry for the long response. 

    Regards 
    Mikolaj


  • 0 in reply to Mikolaj P
    TI__Mastermind 22680 points

    Hi Mikolaj,

    Neehar Sawant said:
    Additionally, I would not recommend using this GPIO configuration as you have GPIO in the same bank generating interrupts on different cores. Since our driver uses banked interrupts, it can cause false interrupts to occur on MCU2_0 or MCU2_1

    Do you have an update on if you have made any adjustments to your GPIO allocations for each core? This may cause serious issues in the future.

    Mikolaj P said:
    GPIO_socConfigIntrPath() returns only 0 values on both cores (mcu2_0 and mcu2_1)

    I would recommend manually adjusting the dst_host_irq value using the information from the following FAQ, with information on setting the destination irq. Then check the return value of the Sciclient_rmIrqSet(). We have already raised this issue to the development team and they are working on releasing a fix for this.

    Thanks,

    Neehar