Zephyr: cc13xx and cc26xx handler for IRQ invoked multiple times

[statropy]

Describe the bug
Building networking samples (such as echo_server) with 802.15.4 support enabled for TI cc1352r1_launchxl or cc26x2r1_launchxl fails to complete because of apparent multiple assignments for the CPE0 interrupt handler.

To Reproduce
west build -p always -b cc1352r1_launchxl samples/net/sockets/echo_server -- -DCONF_FILE="prj.conf overlay-802154.conf"
OR
west build -p always -b cc26x2r1_launchxl -d ../build/echo_server samples/net/sockets/echo_server -- -DCONF_FILE="prj.conf overlay-802154.conf"

Expected behavior
Samples should build with 802.15.4 support and without error.

The 2 places this interrupt is referenced are:
ieee802154_cc13xx_cc26xx_init() in /zephyr/drivers/ieee802154/ieee804154_cc13xx_cc26xx.c: IRQ_CONNECT(CC13XX_CC26XX_CPE0_IRQ ...

HwiP_construct() in /modules/hal/ti/simplelink/kernel/zephyr/dpl/HwiP_zephyr.c:
IRQ_CONNECT(INT_RFC_CPE_0 - 16, ...

But HwiP_construct() is never called and that IRQ_CONNECT call should be ignored by gen_isr_tables.py.

Impact
802.15.4 support cannot be included for cc1352r and cc26x2r SOCs.

Screenshots or console output
Build output excerpt with the --debug flag to gen_isr_tables.py args shows multiple assignments for IRQ 9 (CPE0).

The map file shows that HwiP_construct is in the discarded section, and then presumably should not be used by gen_isr_tables.py to determine the ISR table.

.text.HwiP_construct 0x0000000000000000 0xa4 modules/ti/simplelink/lib..__modules__hal__ti__simplelink.a(HwiP_zephyr.c.obj)

Environment (please complete the following information):

• OS: MacOS
• Toolchain: Zephyr SDK/west
• Commit SHA or Version used:
  hal_ti modules/hal/ti b25d4b83b16e52f501f8cd360f4efb8c31ffb578
  zephyr: bf46bee91702ae658b4db4d0088a1afa60c0676c

Additional context
Commenting out the call to IRQ_CONNECT(INT_RFC_CPE_0 - 16, ... in HwiP_zephyr.c allows the build to complete and the samples seem to work as intended.
@cfriedt @vanti @bwitherspoon

[cfriedt]

Ah cool. I'll take a look at this now

[cfriedt]

But HwiP_construct() is never called and that IRQ_CONNECT call should be ignored by gen_isr_tables.py.

I was using it for the BLE port in #21631 . Specifically, here via RF_open(), iirc.

From my discussions with TI, it was preferable to keep the RF IRQ's in hal/ti in order to use more of the TI RF driver library. Is that a discussion we want to open up again?

[galak]

Hmm, when I try:

west build -p always -b cc1352r1_launchxl samples/net/sockets/echo_server -- -DCONF_FILE="prj.conf overlay-802154.conf"

I'm getting:

In file included from /home/galak/git/modules/hal/ti/simplelink/source/ti/devices/cc13x2_cc26x2/./driverlib/rfc.h:62,
                 from /home/galak/git/zephyr/drivers/ieee802154/ieee802154_cc13xx_cc26xx.c:25:
/home/galak/git/modules/hal/ti/simplelink/source/ti/devices/DeviceFamily.h:178:6: error: #error "DeviceFamily_XYZ undefined. You must define a DeviceFamily_XYZ!"
  178 |     #error "DeviceFamily_XYZ undefined. You must define a DeviceFamily_XYZ!"
      |      ^~~~~
/home/galak/git/modules/hal/ti/simplelink/source/ti/devices/DeviceFamily.h:209:39: fatal error: ti/devices/DeviceFamily_DIRECTORY/inc/hw_types.h: No such file or directory
  209 | #define DeviceFamily_constructPath(x) <ti/devices/DeviceFamily_DIRECTORY/x>
      |                                       ^
compilation terminated.
gmake[2]: *** [zephyr/CMakeFiles/zephyr.dir/build.make:668: zephyr/CMakeFiles/zephyr.dir/drivers/ieee802154/ieee802154_cc13xx_cc26xx.c.obj] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2659: zephyr/CMakeFiles/zephyr.dir/all] Error 2
gmake: *** [Makefile:104: all] Error 2
FATAL ERROR: command exited with status 2: /usr/bin/cmake --build /home/galak/git/zephyr/build

[galak]

I guess the HAL version is at c398cc7959097d27a9cfec857eeade9b851cd46c

[cfriedt]

@galak - still getting that error? Should be defined in

hal/ti/simplelink/source/ti/devices/cc13x2_cc26x2/CMakeLists.txt

[vanti]

I think the output from @galak is due to the latest update of rfc.h when moving to SimpleLink SDK 4.10. It now requires DeviceFamily_CC13X2to be defined.

When I try to add a compiler definition in drivers/ieee802154/CMakeLists.txt:

set_source_files_properties(ieee802154_cc13xx_cc26xx.c
  PROPERTIES COMPILE_DEFINITIONS "DeviceFamily_CC13X2;${COMPILER}" )

The build seems to ignore this directive. Not sure what is the right syntax for this?

As for the error from @statropy, short term HwiP_construct() can be modified to not connect the irq for CPE0, which would prevent the conflict if there isn't a more elegant solution. Longer term I think we should look into converting the ieee802154 driver to use the TI RF driver as well, so that it can be used concurrently with future BLE work.

[cfriedt]

@vanti - what's your ballpark for longer term?

[vanti]

@statropy I took a stab at the fix in #25307, since there seems to be other gremlins when rebuilding the sample using the latest HAL. See if it works for you.

@vanti - what's your ballpark for longer term?

@cfriedt After Zephyr 2.3. Timeline would also depend on who is doing the work. Personally I would need some time to ramp up on IEEE 802.15.4, the TI RF driver, etc., given these are not aspects I am familiar with.

[cfriedt]

@vanti - @statropy should be good to start the work.