Potential double `steal()` in ITM logger? Initialization order not clear

[timblakely]

Heya!

Working through getting the ITM logger up and running and having a bit of a hard time wrapping my head around how exactly the initialization should be done. It looks like in nearly every example there's a call to initialize the logger with utilities::logger::init();. In logger.rs, if the log-itm feature is enabled init() is called with the lazy static. Inside the lazy static there's a steal() when doing the destination::Itm::new(&LOGGER) here. If the underlying logging machinery ends up dereferencing the logger and executing the lazy static initializer, the ITM is stolen and the PAC is marked TAKEN in the cortex_m crate here.

That appears to cause issues with the subsequent line in all the examples: let dp = pac::Peripherals::take().unwrap();. Inside of take() it checks whether TAKEN has been modified and returns None, causing the unwrap() to panic.

I'm new to the H7 HAL - spent most of my time in the G4 PAC - so there's a pretty good chance I'm just missing something, not setting a feature flag, or mixing and matching problematic cortex_m* crates, so please bear with me if I'm not getting something obvious 🥴

[richardeoin]

Thanks for reporting this! Many of the example have this problem with the log-itm flag, it needs to be fixed.

The intention when adding ITM logging was that utilities::logger::init() would come after pac::Peripherals::take() in every example, but that's not the case. It's also not caught be CI since we don't actually run the examples (no hardware in the loop)