gh-raspberrypi/pico-sdk
Watch
1
0
Fork
You've already forked pico-sdk
 0
Code Issues 262 Pull requests 63 Releases Activity

Software IRQs missing from RP2350 SVD #1898

New issue
Closed
opened 2024-09-02 04:00:04 -05:00 by pta2002 · 16 comments
pta2002 commented 2024-09-02 04:00:04 -05:00 (Migrated from github.com)

According to the RP235x datasheet, there are 6 spare IRQs which can be used for software interrupts:

IRQ Interrupt Source
46 SPAREIRQ_IRQ_0
47 SPAREIRQ_IRQ_1
48 SPAREIRQ_IRQ_2
49 SPAREIRQ_IRQ_3
50 SPAREIRQ_IRQ_4
51 SPAREIRQ_IRQ_5

However, these are not defined in the SVD, meaning things like the rp235x-pac rust crate don't expose them. (see also: https://github.com/rp-rs/rp235x-pac/issues/4)

According to the RP235x datasheet, there are 6 spare IRQs which can be used for software interrupts: | IRQ | Interrupt Source | |-----|-------------------| | 46 | `SPAREIRQ_IRQ_0` | | 47 | `SPAREIRQ_IRQ_1` | | 48 | `SPAREIRQ_IRQ_2` | | 49 | `SPAREIRQ_IRQ_3` | | 50 | `SPAREIRQ_IRQ_4` | | 51 | `SPAREIRQ_IRQ_5` | However, these are not defined in the SVD, meaning things like the `rp235x-pac` rust crate don't expose them. (see also: https://github.com/rp-rs/rp235x-pac/issues/4)
lurch commented 2024-09-02 04:09:43 -05:00 (Migrated from github.com)

ping @matiasilva
(IIRC there's also some "spare" IRQs on RP2040 which can be used for software interrupts? Ah yes, RP2040 datasheet says "The core can still be forced to enter the relevant interrupt handler by writing bits 26 to 31 in the NVIC ISPR register")

ping @matiasilva (IIRC there's also some "spare" IRQs on RP2040 which can be used for software interrupts? Ah yes, RP2040 datasheet says "The core can still be forced to enter the relevant interrupt handler by writing bits 26 to 31 in the NVIC ISPR register")
pta2002 commented 2024-09-02 05:56:42 -05:00 (Migrated from github.com)

ping @matiasilva (IIRC there's also some "spare" IRQs on RP2040 which can be used for software interrupts? Ah yes, RP2040 datasheet says "The core can still be forced to enter the relevant interrupt handler by writing bits 26 to 31 in the NVIC ISPR register")

Yes, as far as I can tell those are also not on the RP2040 SVD, but they are also not named on the datasheet there.

> ping @matiasilva (IIRC there's also some "spare" IRQs on RP2040 which can be used for software interrupts? Ah yes, RP2040 datasheet says "The core can still be forced to enter the relevant interrupt handler by writing bits 26 to 31 in the NVIC ISPR register") Yes, as far as I can tell those are also not on the RP2040 SVD, but they are also not named on the datasheet there.
matiasilva commented 2024-11-23 04:11:42 -06:00 (Migrated from github.com)

Hi all, thanks for raising this. These spare IRQs were not present in the previous SVD either. The main issue here is that the SVD spec requires interrupts to be attached to a peripheral (https://arm-software.github.io/CMSIS_5/SVD/html/elem_peripherals.html#elem_interrupt). As these are spare, they don't have a peripheral source. I suppose we could lump them with the NVIC?

Hi all, thanks for raising this. These spare IRQs were not present in the previous SVD either. The main issue here is that the SVD spec requires interrupts to be attached to a peripheral (https://arm-software.github.io/CMSIS_5/SVD/html/elem_peripherals.html#elem_interrupt). As these are spare, they don't have a peripheral source. I suppose we could lump them with the NVIC?
Wren6991 commented 2024-11-23 04:24:46 -06:00 (Migrated from github.com)

As these are spare, they don't have a peripheral source.

It's actually weirder than that: there is a dummy peripheral called SPAREIRQ in the RTL to ensure those IRQ numbers are not accidentally reused (which is where the intctrl.h name comes from) but we can't add that to the SVD either because it doesn't have an address

> As these are spare, they don't have a peripheral source. It's actually weirder than that: there is a dummy peripheral called SPAREIRQ in the RTL to ensure those IRQ numbers are not accidentally reused (which is where the `intctrl.h` name comes from) but we can't add that to the SVD either because it doesn't have an address
Wren6991 commented 2024-11-23 04:31:20 -06:00 (Migrated from github.com)

https://github.com/rp-rs/rp235x-pac/pull/5/files so the SVD patch uses a dummy peripheral with a NULL address and no registers. @matiasilva can you think of any issues with that? It seems a bit less dirty than assigning interrupt outputs to the NVIC.

Let me know if you need the same peripheral to exist in RP2040 RTL.

https://github.com/rp-rs/rp235x-pac/pull/5/files so the SVD patch uses a dummy peripheral with a NULL address and no registers. @matiasilva can you think of any issues with that? It seems a bit less dirty than assigning interrupt outputs to the NVIC. Let me know if you need the same peripheral to exist in RP2040 RTL.
matiasilva commented 2024-11-23 04:38:50 -06:00 (Migrated from github.com)

Aha! Yes, I'll get that in then. It would be nice to get the same on RP2040, yes.

Aha! Yes, I'll get that in then. It would be nice to get the same on RP2040, yes.
jannic commented 2024-11-23 05:35:22 -06:00 (Migrated from github.com)

A peripheral with a null address could be a problem for svd2rust generated peripheral access crates. Because converting null pointers to references is UB even if the type is zero-sized and never dereferenced, AFAIK. However I guess this is a limitation of svd2rust and could be fixed there.

A peripheral with a null address could be a problem for svd2rust generated peripheral access crates. Because converting null pointers to references is UB even if the type is zero-sized and never dereferenced, AFAIK. However I guess this is a limitation of svd2rust and could be fixed there.
pta2002 commented 2024-11-23 06:39:51 -06:00 (Migrated from github.com)

A peripheral with a null address could be a problem for svd2rust generated peripheral access crates. Because converting null pointers to references is UB even if the type is zero-sized and never dereferenced, AFAIK. However I guess this is a limitation of svd2rust and could be fixed there.

Not sure if that's necessarily a problem, this is the approach rp2040-pac takes, and which I copied when I created the PR for rp235x-pac (see here: github.com/rp-rs/rp2040-pac@89e78ff078/svd/rp2040.yaml (L766-L788))

> A peripheral with a null address could be a problem for svd2rust generated peripheral access crates. Because converting null pointers to references is UB even if the type is zero-sized and never dereferenced, AFAIK. However I guess this is a limitation of svd2rust and could be fixed there. Not sure if that's necessarily a problem, this is the approach `rp2040-pac` takes, and which I copied when I created the PR for `rp235x-pac` (see here: https://github.com/rp-rs/rp2040-pac/blob/89e78ff078d88cfbbad91bd5aa4eb4ac79a57dab/svd/rp2040.yaml#L766-L788)
jannic commented 2024-11-24 13:33:59 -06:00 (Migrated from github.com)

Indeed, for svd2rust generated pacs this isn't an issue: Since github.com/rust-embedded/svd2rust@82ebef29e8 (from 2017), empty register blocks won't be added to the Peripherals struct. This doesn't completely invalidate my argument, because there is some special handling needed to avoid potential unsoundness. But it also shows that there's precedence for taking that route. (https://github.com/rust-embedded-community/tm4c-rs/blob/master/svd/tm4c129x.xml#L25 is another example). It seems to be a common approach and shouldn't be too surprising, so code-generators likely handle it gracefully.

Thanks for pointing that out, @pta2002!

Indeed, for svd2rust generated pacs this isn't an issue: Since https://github.com/rust-embedded/svd2rust/commit/82ebef29e8716f3d050ef83e96ea8bcbc403cfcb (from 2017), empty register blocks won't be added to the `Peripherals` struct. This doesn't completely invalidate my argument, because there is some special handling needed to avoid potential unsoundness. But it also shows that there's precedence for taking that route. (https://github.com/rust-embedded-community/tm4c-rs/blob/master/svd/tm4c129x.xml#L25 is another example). It seems to be a common approach and shouldn't be too surprising, so code-generators likely handle it gracefully. Thanks for pointing that out, @pta2002!
kilograham commented 2025-02-18 13:03:35 -06:00 (Migrated from github.com)

moved to 2.1.2 pending feedback on #2271

moved to 2.1.2 pending feedback on #2271
lurch commented 2025-03-28 07:54:29 -05:00 (Migrated from github.com)

@kilograham On a similar note, I've just noticed that Table 94 in https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf (on page 83) lists IRQ numbers 40 and 41 as PROC0_IRQ_CTI and PROC1_IRQ_CTI, but these also appear to be missing from the RP2350.svd ?

@kilograham On a similar note, I've just noticed that Table 94 in https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf (on page 83) lists IRQ numbers 40 and 41 as `PROC0_IRQ_CTI` and `PROC1_IRQ_CTI`, but these also appear to be missing from the `RP2350.svd` ?
kilograham commented 2025-03-28 11:24:38 -05:00 (Migrated from github.com)

@kilograham On a similar note, I've just noticed that Table 94 in https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf (on page 83) lists IRQ numbers 40 and 41 as PROC0_IRQ_CTI and PROC1_IRQ_CTI, but these also appear to be missing from the RP2350.svd ?

please open a separate issue and assign to @matiasilva

> [@kilograham](https://github.com/kilograham) On a similar note, I've just noticed that Table 94 in https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf (on page 83) lists IRQ numbers 40 and 41 as `PROC0_IRQ_CTI` and `PROC1_IRQ_CTI`, but these also appear to be missing from the `RP2350.svd` ? please open a separate issue and assign to @matiasilva
👍 1
kilograham commented 2025-03-28 11:25:10 -05:00 (Migrated from github.com)

... as this one is actually already merged into develop

... as this one is actually already merged into develop
🎉 1
kilograham commented 2025-07-29 17:29:49 -05:00 (Migrated from github.com)

this was not fixed in 2.2.0

this was not fixed in 2.2.0
lurch commented 2025-07-29 18:21:10 -05:00 (Migrated from github.com)

Hmmm, I think that #2380 (adding PROC0_IRQ_CTI and PROC1_IRQ_CTI) wasn't fixed in 2.2.0, but this issue is (still) fixed in 2.2.0, because https://raw.githubusercontent.com/raspberrypi/pico-sdk/refs/heads/master/src/rp2350/hardware_regs/RP2350.svd contains:

    <peripheral>
        <name>SPARE_IRQ</name>
        <baseAddress>0x00000000</baseAddress>
        <addressBlock>
            <offset>0</offset>
            <size>4</size>
            <usage>reserved</usage>
        </addressBlock>
        <interrupt>
            <name>SPARE_IRQ_0</name>
            <value>46</value>
        </interrupt>
        <interrupt>
            <name>SPARE_IRQ_1</name>
            <value>47</value>
        </interrupt>
        <interrupt>
            <name>SPARE_IRQ_2</name>
            <value>48</value>
        </interrupt>
        <interrupt>
            <name>SPARE_IRQ_3</name>
            <value>49</value>
        </interrupt>
        <interrupt>
            <name>SPARE_IRQ_4</name>
            <value>50</value>
        </interrupt>
        <interrupt>
            <name>SPARE_IRQ_5</name>
            <value>51</value>
        </interrupt>
    </peripheral>

? 🤔

Hmmm, I think that #2380 (adding PROC0_IRQ_CTI and PROC1_IRQ_CTI) wasn't fixed in 2.2.0, but _this_ issue is (still) fixed in 2.2.0, because https://raw.githubusercontent.com/raspberrypi/pico-sdk/refs/heads/master/src/rp2350/hardware_regs/RP2350.svd contains: ```xml <peripheral> <name>SPARE_IRQ</name> <baseAddress>0x00000000</baseAddress> <addressBlock> <offset>0</offset> <size>4</size> <usage>reserved</usage> </addressBlock> <interrupt> <name>SPARE_IRQ_0</name> <value>46</value> </interrupt> <interrupt> <name>SPARE_IRQ_1</name> <value>47</value> </interrupt> <interrupt> <name>SPARE_IRQ_2</name> <value>48</value> </interrupt> <interrupt> <name>SPARE_IRQ_3</name> <value>49</value> </interrupt> <interrupt> <name>SPARE_IRQ_4</name> <value>50</value> </interrupt> <interrupt> <name>SPARE_IRQ_5</name> <value>51</value> </interrupt> </peripheral> ``` ? 🤔
lurch commented 2026-04-23 04:17:59 -05:00 (Migrated from github.com)

Closing, as this is already fixed on master :

$ git grep SPARE_IRQ "*.svd"
src/rp2040/hardware_regs/RP2040.svd:        <name>SPARE_IRQ</name>
src/rp2040/hardware_regs/RP2040.svd:            <name>SPARE_IRQ_0</name>
src/rp2040/hardware_regs/RP2040.svd:            <name>SPARE_IRQ_1</name>
src/rp2040/hardware_regs/RP2040.svd:            <name>SPARE_IRQ_2</name>
src/rp2040/hardware_regs/RP2040.svd:            <name>SPARE_IRQ_3</name>
src/rp2040/hardware_regs/RP2040.svd:            <name>SPARE_IRQ_4</name>
src/rp2040/hardware_regs/RP2040.svd:            <name>SPARE_IRQ_5</name>
src/rp2350/hardware_regs/RP2350.svd:        <name>SPARE_IRQ</name>
src/rp2350/hardware_regs/RP2350.svd:            <name>SPARE_IRQ_0</name>
src/rp2350/hardware_regs/RP2350.svd:            <name>SPARE_IRQ_1</name>
src/rp2350/hardware_regs/RP2350.svd:            <name>SPARE_IRQ_2</name>
src/rp2350/hardware_regs/RP2350.svd:            <name>SPARE_IRQ_3</name>
src/rp2350/hardware_regs/RP2350.svd:            <name>SPARE_IRQ_4</name>
src/rp2350/hardware_regs/RP2350.svd:            <name>SPARE_IRQ_5</name>
Closing, as this is already fixed on `master` : ```bash $ git grep SPARE_IRQ "*.svd" src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ</name> src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ_0</name> src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ_1</name> src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ_2</name> src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ_3</name> src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ_4</name> src/rp2040/hardware_regs/RP2040.svd: <name>SPARE_IRQ_5</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ_0</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ_1</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ_2</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ_3</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ_4</name> src/rp2350/hardware_regs/RP2350.svd: <name>SPARE_IRQ_5</name> ```
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
rpi-connect-preview
ns-alpha
combine-uf2s
powman-fixups
persistent-data-docs
develop
aon-docs-fix
default-uart-fixups
async-context-deinit-freertos
sdk-time-critical
riscv-flag-check
multi-gcc-riscv-scrict-align
multi-gcc-develop
another-sleep-fix
powman-default-tick
bootrom_sysinfo_tweaks
board_header_checks
mbedtls-file-lists
use_count_of
vtable-per-core
stdio-usb-reset-compat
pico-aes
better-package
ditch_pico_pio_version
ns-develop
hardware-header-updates
low-power-ci
pioasm-cflags
lurch-patch-4
lurch-patch-3
rom_version
iar/develop
2.3.1
2.3.0
2.2.0
2.1.0-correct-picotool
2.1.1-correct-picotool
2.1.1
2.1.0
2.0.0
1.5.1
1.5.0
1.4.0
1.3.1
1.3.0
1.2.0
1.1.2
1.1.1
1.1.0
1.0.1
1.0.0
Labels
Clear labels   
bazel

   
bluetooth

   
board settings

   
boot_stage2

   
bug
Something isn't working

  
build

   
c++

   
can't reproduce
Can not reproduce the bug

  
clang

   
clib-interface

   
cmsis

   
code cleanliness

   
code size

   
compiler version issues

   
cyw43_driver

   
debug

   
discussion

   
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
dynamic_clock

   
elf2uf2

   
enhancement
New feature or request

  
errata

   
filesystem

   
flash layout

   
floating point

   
FreeRTOS

   
hardware_adc

   
hardware_claim

   
hardware_clocks

   
hardware_dma

   
hardware_exception

   
hardware_flash

   
hardware_gpio

   
hardware_i2c

   
hardware_irq

   
hardware_pio

   
hardware_pwm

   
hardware_rcp

   
hardware_rtc

   
hardware_spi

   
hardware_sync

   
hardware_uart

   
hardware_vreg

   
hardware_watchdog

   
hardware_xosc

   
help wanted
Extra attention is needed

  
host

   
IAR

   
installation

   
invalid
This doesn't seem right

  
linker scripts

   
lto

   
lwip

   
mbedtls

   
missing API

   
needs reporter detail

   
networking

   
newlib

   
newlib-multicore

   
non-c

   
non-cmake

   
non-gcc

   
openocd

   
orphan PR

   
OS integration

   
pico_async_context

   
pico_base

   
pico_binary_info

   
pico_flash

   
picolibc

   
pico_lwip

   
pico_malloc

   
pico_multicore

   
pico_printf

   
pico_runtime

   
pico_stdio

   
pico_stdio_usb

   
pico_sync

   
pico_time

   
pico_util

   
pioasm

   
port
issues or discussions of porting code/libraries to rp2040

  
question
Further information is requested

  
review

   
review2

   
rtos interop
Consideration for FreeRTOS co-existence

  
runtime init

   
static library

   
svd

   
test

   
tinyusb

   
vscode

   
wifi integration

   
wontfix
This will not be worked on

No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
Milestone
Clear milestone
No items
No milestone
2.3.0
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk#1898
No description provided.