IRQ_CONNECT: build error "gen_isr_tables.py: error: multiple registrations at table_index [...]"

[BrunoMelaneoVolpi]

Hi everyone,
apologies if this question has already been posed somewhere but unfortunately I was not able to find the answer I am looking for...

In a nutshell, I am trying to use some hardware functionalities provided by some STM32 timers (STM32F7 / nucleo STM32F746zg in my case).
Because my application is time critical, I am aiming to use the hardware as much as possible.
My objective is to:

• Chain several MCU timers using their Master Slave capabilities and their events (TRGI and TRGO) to communicate with each other
• Use DMA to capture a timer register when event TIM1_TRIG is triggered.

This way the MCU timers hardware does almost everything without any software intervention except for a DMA ISR.

I was able to prototype this implementation using a bare metal STM HAL.
Because it worked as expected, I am now trying to incorporate this into my Zephyr work project.

If my research (sniffing Zephyr's code) is correct, these timer-chaining features are not supported by Zephyr and/or its STM32 drivers. (Can anyone confirm?)
As such, I am trying to incorporate� the bare metal prototype directly. Because STM's HAL/LL is used at Zephyr driver level I assumed this could be a valid way forward.

The problem I am facing is that I got to a point where I must register the DMA callback and I am not able to.
I am trying to use IRQ_CONNECT() to register my DMA callback as follows:

    IRQ_CONNECT(DT_IRQ_BY_IDX(DMA2_NODE, 0, irq),
                DT_IRQ_BY_IDX(DMA2_NODE, 0, priority),
                dma_stream0_ch6_stm32_isr,
                &user_data,
                0);
    
    irq_enable(DT_IRQ_BY_IDX(DMA2_NODE, 0, irq));

... but I get the following build error:

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

My implementation should be the only one using the DMA2_Stream0 IRQ.

As such, I was wondering if someone could lead/support me :

**... determining who/where is the same DMA2_Stream0 IRQ being IRQ_CONNECTed?**
** ... preventing the DMA2_Stream0 IRQ from being used elsewhere?**

Using the CONFIG_SHARED_INTERRUPTS does not seem the correct option because as mentioned:
https://docs.zephyrproject.org/latest/kernel/services/interrupts.html#sharing-interrupt-lines
... its usage carries some penalties:
"[...]Please note that enabling CONFIG_SHARED_INTERRUPTS will result in a non-negligible increase in the binary size. Use with caution.[...]"

Moreover, this interrupt line sharing would cause the other unwanted ISR to be executed as well:
"[...]the interrupt line will become shared, meaning the two ISR/argument pairs (previous one and the one that has just been registered) will be invoked each time the interrupt is triggered[...]"
... which could affect my application timings

[erwango]

If my research (sniffing Zephyr's code) is correct, these timer-chaining features are not supported by Zephyr and/or its STM32 drivers. (Can anyone confirm?)

I confirm

... but I get the following build error: [...]
My implementation should be the only one using the DMA2_Stream0 IRQ.

Most likely the code you're using enabled DMA2 from dma_stm32.c drivers which is itself enabling this IRQ, eventually colliding with your code.

[BrunoMelaneoVolpi]

Hi erwango,
Thank you for your reply!
That is the suspicion I got while going through the stm drivers code.
I tried to confirm those suspicions by tracing the code 0x8000f2d of the existing handler to the actual src code, but was not able to.
Existing handler 0x8000f2d, new handler 0x800bd01
I didn't find references to 0x8000f2d in the build folder.

Would you by any chance know if / how one could prevent the stm32 dma driver from enabling this IRQ? Or alternatively, how can I disable it before re-enabling back for my application?

[erwango]

Would you by any chance know if / how one could prevent the stm32 dma driver from enabling this IRQ? Or alternatively, how can I disable it before re-enabling back for my application?

That really depends on what you expect from existing dma driver, but you can try to comment out lines here:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/dma/dma_stm32.c#L767
Other wise you can try to make sure it doesn't compile from CMakeLists.txt file

[BrunoMelaneoVolpi]

Hi erwango,
thank you for your input.
It looks like by using the STM32_DMA_HAL_OVERRIDE flag in the linked_channel, one can register our callback and because it also causes the DMA driver to relinquish control of the DMA stream, one can control the stream as we intend.

Unfortunately, I am still new to Zephyr and still cannot properly navigate my way around the documentation, so I could not find this linked_channel / STM32_DMA_HAL_OVERRIDE feature documented anywhere. I tripped over it while trying to understand the DMA driver code.

[erwango]

Great that it could work for you this way.
Indeed such specific behavior are not easy guess, but it is not easy to make it appear properly in documentation neither. This would be quite useful indeed. Maybe @kartben you can have good advices on how we should/could document things as STM32_DMA_HAL_OVERRIDE in include/zephyr/drivers/dma/dma_stm32.h?