Software IRQs missing from RP2350 SVD

[pta2002]

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]

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]

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]

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]

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]

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]

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

[jannic]

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]

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]

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]

moved to 2.1.2 pending feedback on #2271

[lurch]

@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]

@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]

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

[kilograham]

this was not fixed in 2.2.0

[lurch]

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>

? 🤔