* Hi all! I'm doing a little experiment (mainly as a learning experience) where I'm frankensteining together a way to run a piece of firmware directly on the host, deferring operations that can only be run on the MCU to probe-rs. Idea is to be able to shorten the feedback loop of embedded developers, by skipping the flash erase and program steps. Disclaimer: as mentioned, this is an experiment, to explore if this is even possible, and making things portable and beautiful is explicitly not on my TODO list. Currently, I've got a simple PAC and `cortex_m::asm::Delay` based blinky application working, which runs on my linux pc, but has the LED of my nucleo board flashing. Pretty neat! The MCU runs a firmware that does basically this: ```rust fn main() -> ! { loop { call_target(); } } [..] #[no_mangle] #[used] #[link_section = ".target_fn_data"] static mut TARGET_FN: u32 = 0; #[no_mangle] #[used] #[link_section = ".target_fn_data"] static mut TARGET_FN_INPUT: [u8; 1024] = [0; 1024]; #[no_mangle] #[used] #[link_section = ".target_fn_data"] static mut TARGET_FN_OUTPUT: [u8; 1024] = [0; 1024]; pub fn call_target() { let target_fn = unsafe { &mut TARGET_FN }; if *target_fn != 0 { let f: fn() = unsafe { core::mem::transmute(*target_fn) }; log::trace!("Calling target {:08x}", *target_fn); f(); log::trace!("Done calling target {:08x}", *target_fn); *target_fn = 0; } } ``` I'm manipulating the statics using the debugger directly, which has the MCU call the corresponding function with the passed input. Highly unsafe and ugly, but hey, it works! Next step of course is brining in the big guns, i.e. Embassy. My goal is to have the [embassy stm32L4 blinky example](https://github.com/embassy-rs/embassy/blob/main/examples/stm32l4/src/bin/blinky.rs) run on my host. Loads of stuff to figure out, but the thing I'm stuck on currently, is the step where `embassy::init` configures the RTC (I think?). Specifically, my application hangs on the following line: https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/src/rcc/bd.rs#L69 Now in my logs I can see that the call to `modify` on the line prior to this one is indeed executed, with a value that seems correct (bit 8 is indeed 1), but reading it never yields the value just written. Is the DAP doing something magical here that I'm not grasping?