• State Verified Answer
  • Replies 4 replies
  • Subscribers 65 subscribers
  • Views 181 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 330248
Options

Multiple IRQ registration build error when migrating from NCS 2.5.0 to 2.7.0

taspon98

Hello,

I am encountering the following multi registration error when migrating from 2.5.0 to 2.7.0. I don't really have any good way to debug this as the application was able to compile successfully using the 2.5.0 SDK. Any help or pointers would be greatly appreciated. Thanks!

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

Parents
  • 0

    Setting CONFIG_SHARED_INTERRUPTS=y fixes the issue although I am unsure what underlying SDK modules are using the same interrupt.

  • 0 in reply to taspon98

    This error typically happens when something is getting configured twice, once under/from zephyr, and other manually / intentionally.

    I am not sure what your application is, but have you changed it (maybe you added some configuration etc) while migrating?

    Nonetheless, good to know that it is solved using this config.

  • 0 in reply to Naeem Maroof

    I haven't changed any configuration when migrating to 2.7.0. The conflict seems to be due to the Zephyr implementation of the software BLE link layer and the PWM driver. Turning off CONFIG_BT_LL_SW_SPLIT=y and using the nordic LL driver fixes the issue but with the drawback of RAM demand also getting increased by another 1kB. Is there perhaps a way to fix this since I would like to use the NRF PWM driver for the CAF LED module along with the Zephyr BLE stack.

  • +1 in reply to taspon98

    I was able to finally resolve the issue. Turns out there is an anomaly behavior for PWM (Anomaly 109) that somehow causes the nRF52832 to enter the IDLE state and stops the 64Mhz clock at the same time the PWM starts using the DMA which causes the wrong data to get sent. To resolve this issue, it appears nordic have been using a software interrupt in the past to wake up the CPU to start the DMA transfer. the option NRF52_ANOMALY_109_WORKAROUND_EGU_INSTANCE is currently default to EGU instance 4 (used to be 5) in the recent 2.6.0 since the multiprotocol service layer libraries (MPSL) is currently using EGU5. This explains why there wasn't any conflict with the zephyr BLE LL driver in 2.5.0. I changed the EGU setting back to 5 (CONFIG_NRF52_ANOMALY_109_WORKAROUND_EGU_INSTANCE = 5) and that seem to resolve the conflict.

Reply
  • +1 in reply to taspon98

    I was able to finally resolve the issue. Turns out there is an anomaly behavior for PWM (Anomaly 109) that somehow causes the nRF52832 to enter the IDLE state and stops the 64Mhz clock at the same time the PWM starts using the DMA which causes the wrong data to get sent. To resolve this issue, it appears nordic have been using a software interrupt in the past to wake up the CPU to start the DMA transfer. the option NRF52_ANOMALY_109_WORKAROUND_EGU_INSTANCE is currently default to EGU instance 4 (used to be 5) in the recent 2.6.0 since the multiprotocol service layer libraries (MPSL) is currently using EGU5. This explains why there wasn't any conflict with the zephyr BLE LL driver in 2.5.0. I changed the EGU setting back to 5 (CONFIG_NRF52_ANOMALY_109_WORKAROUND_EGU_INSTANCE = 5) and that seem to resolve the conflict.

Children
No Data
Related