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: rp-rs/rp235x-pac#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 rust-embedded/svd2rust@82ebef2 (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!