update NVIC to use derive-mmio

[robamu]

The primary advantage is that derive-mmio does not create shared references to MMIO like VolatileCell / volatile_register does.

[Copilot]

Pull request overview

This PR rewrites the NVIC peripheral implementation to use derive-mmio so MMIO access doesn’t rely on creating shared references (as with VolatileCell / volatile-register).

Changes:

• Introduces derive-mmio and converts the NVIC RegisterBlock to a #[derive(derive_mmio::Mmio)] MMIO model.
• Refactors crate::peripheral::NVIC into an owning wrapper around nvic::MmioRegisterBlock<'static> and updates NVIC methods accordingly.
• Updates peripheral address layout tests to use derive-mmio pointer helpers instead of taking &*NVIC::PTR.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
cortex-m/src/peripheral/nvic.rs	Replaces volatile-register register block with derive-mmio and rewrites NVIC operations to use generated MMIO accessors / raw volatile byte access for IPR on non-armv6m.
cortex-m/src/peripheral/mod.rs	Changes NVIC from a ZST marker with PTR to a wrapper holding MmioRegisterBlock<'static>, and updates Peripherals::steal() construction.
cortex-m/src/peripheral/test.rs	Updates NVIC address assertions to use derive-mmio pointer accessors and NVIC::steal().
cortex-m/Cargo.toml	Adds derive-mmio = "0.6" dependency.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This change removes the long-standing NVIC::PTR / NVIC::ptr() raw-pointer API and changes NVIC from a ZST marker to an owning wrapper. That’s a breaking public API change (and is inconsistent with the other peripherals in this module that still expose PTR). Consider keeping PTR (as a raw pointer/usize base address) and the deprecated ptr() for compatibility, even if you steer users to steal()/derive-mmio accessors.

[robamu]

It is a breaking change anyway. Not sure how useful it would be to keep the old PTR API for the new type.

[Copilot]

NVIC::set_priority (non-armv6m path) uses ptr.offset(...) on an MMIO pointer. As with get_priority, this can be UB under strict provenance because offset requires staying within a single allocated object. Prefer wrapping_add/wrapping_offset (or address arithmetic from BASE_ADDRESS) before calling write_volatile.

Suggested change

	unsafe { core::ptr::write_volatile(ipr_ptr.offset(nr as isize), prio) }
	unsafe { core::ptr::write_volatile(ipr_ptr.wrapping_add(usize::from(nr)), prio) }

[robamu]

this should be fine I think? The pointer is related to the IPR allocation and we assume the interrupt number is valid.

[robamu]

I tested this PR with #655 with https://github.com/ferrous-systems/rust-training/tree/main/example-code/qemu-thumbv7em. Async and interrupt using examples were running fine. I'll probably add some tests to verify priority setting/reading as well because pointer magic was used there..