• State Verified Answer
  • Replies 18 replies
  • Subscribers 66 subscribers
  • Views 2813 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 306040
Options

Need help with nRF5340 IRQ conflict errors when adding GPIOTE drivers to Nordic Bluetooth Peripheral UART project

TrulliDev

We are using the Nordic Bluetooth "Peripheral UART" project as a base for our project and I am attempting to add the GPIOTE drivers to the project but getting the following error:

gen_isr_tables.py: error: multiple registrations at table_index 47 for irq 47 (0x2f)
Existing handler 0x39aa5, new handler 0x39aa5
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

It looks like there is an IRQ conflict with adding the GPIOTE drivers and the DK drivers.

The reason I need the GPIOTE driver is in order to add multiple QDEC rotary encoders (which is not supported by the current QDEC driver).  I have attached a sample app that demonstrates the error.  We are using NCS v2.3.0 targeting nrf5340dk_nrf5340_cpuapp_ns.  We need to deconflict the IRQ but also keep the as much of the DK drivers as possible to expedite this project.

See attached application below:
peripheral_uart_GPIOTE.zip

Thanks for the help!

  • 0

    Hi, We just came back from Easter vacation and that was the reason for no response from out end. Due to very high traffic during this period on devzone and fewer people working this week, we did not manage to assign this to an expert yet. We will look into this as soon as possible, but please expect more delays the first two days. Thanks for your patience so far.

  • 0 in reply to Susheel Nuguru

    Thanks for the notice.  We are trying very hard to get this solved by Thursday or Friday at the latest so any help is greatly appreciated.

  • 0

    I understand.

    You cannot use nrfx_gpiote driver separately when you are using gpio_nrfx.c.

    You need to do what nrf\lib\dk_buttons_and_leds\dk_buttons_and_leds.c did. You need to get the device pointer of gpiote zephyr driver like below

    const struct device *const gpiote = DEVICE_DT_GET_OR_NULL(DT_NODELABEL(gpiote));

    And use this instead of direct nrfx API for GPIOTE. 

    You can register another callback for your application just like nrf\lib\dk_buttons_and_leds\dk_buttons_and_leds.c did.

  • 0 in reply to Susheel Nuguru

    The file dk_buttons_and_leds.c is using loads of macros to abstract away the code to support multiple DKs so referencing the DK code doesn't help me much because I am very unfamiliar with Zephyr and Nordic.

    When you say one CANNOT use GPIO and GPIOTE I assume you mean that it is forbidden to have the following in the prj.conf:
    CONFIG_GPIO=y
    CONFIG_NRFX_GPIOTE=y

    Can you modify my posted application to trigger an event on the rising edge of GPIO pin 37?  I understand you may not be able to test but I would like to see what the code would look like to do this.

    As a side note I have been able to get the generic nrfx GPIOTE sample application working on the nRF5340 even though the 5340 is not listed as supported by the sample application.  However, this application is using no GPIO.

     

  • 0 in reply to TrulliDev
    TrulliDev said:
    When you say one CANNOT use GPIO and GPIOTE I assume you mean that it is forbidden to have the following in the prj.conf:
    CONFIG_GPIO=y
    CONFIG_NRFX_GPIOTE=y

    No, nrfx_gpiote HAL module and gpio_nrfx both work with the expectations that nrfx_gpiote_irq_handler is called to handle the interrupts. gpio_nrfx.c is calling 

    	IRQ_CONNECT(DT_IRQN(GPIOTE_NODE), DT_IRQ(GPIOTE_NODE, priority),
		    nrfx_isr, nrfx_gpiote_irq_handler, 0);
     

    and your application is calling the below in main.c

    	IRQ_CONNECT(DT_IRQN(DT_NODELABEL(gpiote)),
		    DT_IRQ(DT_NODELABEL(gpiote), priority),
		    nrfx_isr, nrfx_gpiote_irq_handler, 0);

    That means you are trying to connect the irq handler twice (Even though both are trying to connect the same irq handler, the linker thinks that this most likely is a mistake and throws an error.

    If you comment out the IRQ_CONNECT thing in your application (as nrfx_gpiote_irq_handler is already registered as irq handler by Zephyr gpio driver gpio_nrfx.c) then you can see that you code will compile. It might work for your case as luckily there does not seems to be anything that gpio_nrfx.c is remembered and there are no status get API that will be affected by using nrfx_gpio.c outside the zephyr driver framework . So you might just be fine by commenting out the IRQ_CONNECT (line 127 of main.c of your application)  you might be able to get what you want.

Related