isr4 repeatedly gets triggered after test passes in tests/kernel/gen_isr_table

[vanti]

Describe the bug
When run as part of the sanitycheck script, tests/kernel/gen_isr_table fails with a timeout on cc1352r1_launchxl:

cc1352r1_launchxl         tests/kernel/gen_isr_table/arch.interrupt          FAILED: timeout
	see: sanity-out/cc1352r1_launchxl/tests/kernel/gen_isr_table/arch.interrupt/handler.log

In the log file 'sanity-out/cc1352r1_launchxl/tests/kernel/gen_isr_table/arch.interrupt/handler.log', isr4 is seen to continue to run after the test passes:

***** Booting Zephyr OS build v2.0.0-rc1-144-g048b0359bcd2 *****
starting test - Test gen_isr_tables
IRQ configuration (total lines 38):
isr1 isr=0x000006a5 irq=37
isr2 isr=0x000006d1 irq=36
Checking _irq_vector_table entry 37 for irq 37
triggering irq 37
isr1 ran
Checking _irq_vector_table entry 36 for irq 36
triggering irq 36
isr2 ran
_sw_isr_table at location 0x20000f44
isr3 isr=0x00000615 irq=35 param=0xb01dface
Checking _sw_isr_table entry 35 for irq 35
triggering irq 35
isr3 ran with parameter 0xb01dface
isr4 isr=0x00000639 irq=34 param=0xca55e77e
Checking _sw_isr_table entry 34 for irq 34
triggering irq 34
isr4 ran with parameter 0xca55e77e
isr5 isr=0x0000065d irq=33 param=0xf0ccac1a
Checking _sw_isr_table entry 33 for irq 33
triggering irq 33
isr5 ran with parameter 0xf0ccac1a
isr6 isr=0x00000681 irq=32 param=0xba5eba11
Checking _sw_isr_table entry 32 for irq 32
triggering irq 32
isr6 ran with parameter 0xba5eba11
PASS - main
============================================================isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e
isr4 ran with parameter 0xca55e77e

To Reproduce
Steps to reproduce the behavior:
To reproduce the timeout, run ./scripts/sanitycheck -p cc1352r1_launchxl --device-testing --device-serial /dev/ttyACM0

You can also build the test separately:

1. mkdir build; cd build
2. cmake .. -DBOARD=CC1352r1_launchxl
3. make flash
4. See error

Expected behavior
The test should not result in a timeout when run as part of the sanitycheck script.

Environment (please complete the following information):

• OS: Ubuntu 18.04
• Toolchain: Zephyr SDK 0.10.3
• Commit SHA tested: a4bd5b6

[ioannisg]

This test, simply, does not work for platforms that do not have all IRQ lines implemented and available (from 0 to CONFIG_NUM_IRQS). E.g. fails in nrf9160_pca10090, too. Needs some rework.

[ioannisg]

Hi @vanti can you please, re-confirm the behavior on CC1352r1_launchxl on current master branch? Is ISR4 keeps being triggered?

[ioannisg]

I don't have the board to re-produce this.

[vanti]

@ioannisg I see an error when I build the test:

$ west build -b cc1352r1_launchxl

...
[127/132] Linking C executable zephyr/zephyr_prebuilt.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       18672 B     360360 B      5.18%
      FLASH_CCFG:          88 B         88 B    100.00%
            SRAM:        4528 B        80 KB      5.53%
        IDT_LIST:         184 B         2 KB      8.98%
[129/132] Generating isr_tables.c
FAILED: zephyr/isr_tables.c 
cd /home/local/zephyrproject-work/zephyr/tests/kernel/gen_isr_table/build/zephyr && /home/local/bin/zephyr-sdk-0.11.1/arm-zephyr-eabi/bin/arm-zephyr-eabi-objcopy --input-target=elf32-littlearm --output-target=binary --only-section=.intList /home/local/zephyrproject-work/zephyr/tests/kernel/gen_isr_table/build/zephyr/zephyr_prebuilt.elf isrList.bin && /usr/bin/python3.6 /home/local/zephyrproject-work/zephyr/arch/common/gen_isr_tables.py --output-source isr_tables.c --kernel /home/local/zephyrproject-work/zephyr/tests/kernel/gen_isr_table/build/zephyr/zephyr_prebuilt.elf --intlist isrList.bin   --sw-isr-table --vector-table
gen_isr_tables.py: multiple registrations at table_index 34 for irq 34 (0x22)
Has IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?
Traceback (most recent call last):
  File "/home/local/zephyrproject-work/zephyr/arch/common/gen_isr_tables.py", line 316, in <module>
    main()
  File "/home/local/zephyrproject-work/zephyr/arch/common/gen_isr_tables.py", line 307, in main
    + "\nHas IRQ_CONNECT or IRQ_DIRECT_CONNECT accidentally been invoked on the same irq multiple times?"
  File "/home/local/zephyrproject-work/zephyr/arch/common/gen_isr_tables.py", line 36, in error
    raise Exception()
Exception
ninja: build stopped: subcommand failed.

[ioannisg]

@vanti now it is clear what is happening here; one of the IRQ lines used in the test is used by the platform, e.g. in some driver. The script actually checks that IRQ_CONNECT is not called (check at build-time) multiple times on the same IRQ line.

AFAIR, this check was added recently. Before this change was added, you were able to build and flash this test to this platform. The log you had earlier posted here makes sense: the IRQ line is used by the platform and keeps firing, causing the test-defined ISR to trigger continuously after the test is completed.

So what we have to do is simply to exclude the platform from this test. For now that's probably ok, and AFAICS this is already the case; but this test is using up to 6 IRQ lines and it is natural that there are conflicts with certain platforms. We need a solution that makes the test aware (at built-time) of what IRQs can be used.

Closing for now as the platform is excluded for this test in CI.