RTEMS | Draft: bsps/riscv/esp32: Make interrupt source 0, the WiFi MAC, usable (!1556)

[Sam Price (@TheSamPrice)]

Sam Price created a merge request: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1556

Project:Branches: TheSamPrice/rtems:esp32c3-irq-source-0 to rtems/rtos/rtems:main
Author: Sam Price

On the ESP32-C3, peripheral interrupt source 0 is the WiFi MAC (`ETS_WIFI_MAC_INTR_SOURCE`). The BSP uses RTEMS vector numbers as peripheral sources, so vector 0 has to work. Three things stopped it:

1. `bsp_interrupt_is_valid_vector()` rejected 0. That's true of CPU interrupt *channel* 0, which the hardware reserves, but not of peripheral *source* 0. The two numbering spaces had been mixed up.
2. `get_active_interrupt()` returned 0 to mean "nothing is asserting", so source 0 firing looked the same as no interrupt. It now returns `NO_ACTIVE_VECTOR` (one past the last vector), and the dispatcher returns early on it instead of indexing past the end of the handler table. That's also the right response to a real spurious interrupt.
3. `irq_mappings[]` had no WiFi entries, so enabling the source failed with `RTEMS_UNSATISFIED`. The WiFi MAC, PWR and BB sources now map to CPU channel 1.

Channel 1 is shared because all 31 usable channels are already assigned. Sharing is already how this table works (four software interrupts share channel 1, EFUSE shares 7 with LEDC, both watchdogs share 14), and it is what the WiFi libraries request (`intr_num` 1 for MAC and PWR). A dynamic mapping would be the better long-term answer.

The two initialisation loops now start at vector 0, so source 0 gets a priority and starts unmapped like every other source.

**Testing:** `riscv/esp32c3db` and its samples build with no warnings. A test program outside this tree checks that vector 0 is valid, that a handler installs on it, and that enable and disable program and clear the interrupt matrix. With only the vector-0 rejection restored, it fails with `RTEMS_INVALID_ID`, the same error the WiFi port was getting. Delivery isn't tested, because a peripheral source can't be raised from software.

Assisted-by: Claude Opus 5 (1M context) <noreply at anthropic.com>

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1556
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-2oxwotksa9relmena8a9klxks-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20261103/88c657f2/attachment.htm>