Enable DCONFIG_NRF_MODEM_LIB_TRACE causes error

AchimKraus

Using ncs 2.4.0 and enable DCONFIG_NRF_MODEM_LIB_TRACE results in:

[348/361] Generating isr_tables.c, isrList.bin
FAILED: zephyr/isr_tables.c zephyr/isrList.bin …/build_feather_nrf9160_ns/zephyr/isr_tables.c …/build_feather_nrf9160_ns/zephyr/isrList.bin
cd …/build_feather_nrf9160_ns/zephyr && …/zephyr-sdk-0.15.2/arm-zephyr-eabi/bin/arm-zephyr-eabi-objcopy –input-target=elf32-littlearm –output-target=binary –only-section=.intList …/build_feather_nrf9160_ns/zephyr/zephyr_pre1.elf isrList.bin && /usr/bin/python3.8 …/zephyr/scripts/build/gen_isr_tables.py –output-source isr_tables.c –kernel …/build_feather_nrf9160_ns/zephyr/zephyr_pre1.elf –intlist isrList.bin –sw-isr-table –vector-table
gen_isr_tables.py: error: multiple registrations at table_index 9 for irq 9 (0×9)
Existing handler 0×43d71, new handler 0×43d71
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?

Is there a way to overcome that?

jaredwolff

Turning this on it will try to occupy one of your UART interfaces (I think the same one as your console). I haven’t played with it enough to know definitively. I’m assuming you’re trying to get a modem trace @AchimKraus?

AchimKraus

Yes, adding a ttl-usb serial and using the cellular monitor or get a modem trace to analyze a misbehavior.
It hasn’t a that “high prio”, though I have enough Thingys:91 and nRF9160 DKs, but I guess, it will get more important in the future, when the feather will get used much more (at least, that’s my plan ;-) ).

jaredwolff

AchimKraus the feather will get used much more

😍

AchimKraus

I’ve investigated on this topic. The nRF9160 peripherals are sharing resources, documented in nRF9160_PS_v2.1 - 4.2.2 Instantiation, page 27. UART1 (UARTE1) and I2C1 (TWIM1) have the same ID 9 and share the resources. So only one can be used at the same time. Depending on the other usage, it may be easier to switch the i2c to i2c3 when uart1 is used for modem tracing. AFAIK, the nRF9160 feather doesn’t use board specific startup code, so it’s mainly the application, which requires then to take care of the different i2c in an overlay.

jaredwolff

AchimKraus you are correct. By default the board definition enables I2C1 but it may need to be remapped as you’re seeing. I was actually trying to get this to work the other day to try and get the cellular monitor working.

AchimKraus

I was already corrected, it’s I2C2 not I2C3, which should be used.