(Kubuntu, NRF5340, nRF ver 2.5.99)
I'm having an issue with the build system - I am working on a project that is based off of the audio sample - I am using a very stripped version that just has USB and I2S enabled for testing purposes.
When I try to build it, it fails on the ISR table generation, saying that I have the IRQ_CONNECT macro in multiple places in my code. (IRQ 40, in this case).
gen_isr_tables.py: (69, 0) gen_isr_tables.py: Configured interrupt routing gen_isr_tables.py: handler irq flags param gen_isr_tables.py: -------------------------- gen_isr_tables.py: 0x24d07 40 0 0x17379 gen_isr_tables.py: 0x24d07 55 0 0x1a821 gen_isr_tables.py: 0x24d07 54 0 0x1a4b9 gen_isr_tables.py: 0xf10d 14 0 0x26ac8 gen_isr_tables.py: 0x24d07 5 0 0x256bd gen_isr_tables.py: 0x24d07 13 0 0x16c65 gen_isr_tables.py: 0x24d07 9 0 0x18b89 gen_isr_tables.py: 0x24d07 40 0 0x17379 gen_isr_tables.py: 0x24d07 42 0 0x1752d gen_isr_tables.py: 0x2241d 8 0 0x26aa0 gen_isr_tables.py: 0x24d07 10 0 0x17fa1 gen_isr_tables.py: 0x130a1 21 0 0x0 gen_isr_tables.py: 0x24d07 24 0 0x1aabd gen_isr_tables.py: offset is 0 gen_isr_tables.py: num_vectors is 69 gen_isr_tables.py: error: multiple registrations at table_index 40 for irq 40 (0x28) Existing handler 0x24d07, new handler 0x24d07 Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?
Whats odd, is I find that when I comment out the following line in audio_i2s_init(), the build passes and the ISR tied to (40) 0x28 still exists, so I don't believe it's a case of the macro appearing twice.
IRQ_CONNECT(DT_IRQN(I2S_NL), DT_IRQ(I2S_NL, priority), nrfx_isr, nrfx_i2s_0_irq_handler, 0);
Some notes:
- The regular Audio application builds just fine and spits out the following irq table:
[453/456] Generating isr_tables.c, isrList.bin gen_isr_tables.py: (69, 0) gen_isr_tables.py: Configured interrupt routing gen_isr_tables.py: handler irq flags param gen_isr_tables.py: -------------------------- gen_isr_tables.py: 0x77b81 40 0 0x4915d gen_isr_tables.py: 0x3e149 14 0 0x7ad00 gen_isr_tables.py: 0x77b81 5 0 0x48061 gen_isr_tables.py: 0x77b81 13 0 0x48af5 gen_isr_tables.py: 0x77b81 9 0 0x4a9a1 gen_isr_tables.py: 0x77b81 42 0 0x49311 gen_isr_tables.py: 0x75031 8 0 0x7acc4 gen_isr_tables.py: 0x77b81 10 0 0x49d41 gen_isr_tables.py: 0x44459 21 0 0x0 gen_isr_tables.py: 0x77b81 24 0 0x4abfd gen_isr_tables.py: offset is 0 gen_isr_tables.py: num_vectors is 69
- I put my own wrapper around the audio_i2s module, but it is otherwise unchanged.
- I have gone so far as to scour the both the project, into the entire SDK to see if there's somewhere else that the interrupt is generated.
- The CMakeLists I have triple checked to make ensure it is not pulling it in twice.
- It fails on both an audio DK and a regular one.
- I can't find any IRQ-related configs that the audio apphas enabled that mine does not.
- This test application was generated from a hello_world_multicore application with the relevant bits from the audio app pulled in.
Any pointers? I did notice that changing the interrupt ID in the device tree changes BOTH of the instances in the gen_isr output, so there's some sort of automatic irq connection happening under the hood where it isn't particularly clear what's happening. Commenting out the IRQ_CONNECT in code does seem to still work, my I2S spins, but the timing seems to not be right and tends to eat all of my CPU time.
