I encountered a bug (in the USART section of the embedded discovery book) where cortex_m::Peripherals::take().unwrap(); was hanging, around the Peripherals::steal() function.
Updating the cortex_m crate from version 0.5.6 to 0.6.3 solved the problem,
However, I did not find a sensible way to force-update the dependency in crates I depend upon such as this, leading to conflicts.

Can we update the dependency here so other people won't have this bug?

Also, as a workaround, is there a way to override the dependency version in packages, without downloading them locally? something like this:

cortex-m = "!0.6.3" #force updates to 0.6.3, regardless of what the package says.

As mentioned in the docs for cortex-m-rtfm, it will only work for a device crate generated using svd2rust 0.14.x.

What would it take to do this?

Shouldn't cortex-m dependency be upgraded to allow dependent crates to move forward?

I didn't notice that this repository had been made when I created:

https://github.com/cwoodall/stm32f303x-memory-map

I believe now that the stm32f30x svd is sufficient, but I have been editing the svd file to create enumeratedValues (specifically for the EXTI related registers for doing Input Interrupts). Let me know what you think about this strategy.

The STM32F3 SPI data register DR can respond to reads and writes differently, based on whether the access is 8 bits wide, or 16 (or more) bits wide. For example, when the configured SPI data frame size is 8 bits or less, a single 16-bit write to DR will be interpreted as two data frames. This is called data packing, and is described in the reference manual (see STM32F303x/328x Reference Manual, RM0316, DM00043574, p.965 "Data Packing").

The stm32f30x crate currently has no way of performing a DR register read or write that is not 32 bits, so e.g. a write using

let data_out: u8 = 0xa5;
(*SPI2.get()).dr.write(|w| w.dr().bits(data_out as u16));

results in two data frames being loaded into the transmit FIFO. As a work-around, one may write

core::ptr::write_volatile(&(*SPI2.get()).dr as *const _ as *mut u8, data_out);

to write a single data frame, but at that point, one may as well be using C. :)

I don't recall, nor could I find in a quick search, any other instances of STM32 peripherals behaving this way, but there may be other circumstances where the access width is important. Since the stm32f30x crate is auto-generated from SVD, maybe support for SPI belongs in a higher-level HAL or BSP. But at minimum, it would be nice if the SVD patch added a bit of documentation on the DR register making note of this.

The documentation link in the README does go anywhere meaningful.

Sorry for potentially stupid question, but how do I set GPIO_MODE_IT_RISING (0x10110000U) if the API is defined using u8?
EDIT: I'm working off the older version used by your tutorial... which seems to look slightly different from the current implementation.