Reprogramming, then quickly WFI-ing, resets Teensy

[mciantyre]

Describe the bug
After you reprogram the Teensy, there's a chance that the chip will reset again when you wait for interrupt (WFI). You'll notice that the Teensy's red, programming LED is on, and your program doesn't run.

To Reproduce
In the pit.rs example, remove the spin-loop:

teensy4-rs/examples/pit.rs

Lines 66 to 69 in b9f297e

	// Chip might stop running if we hit WFI out of reset too fast.
	// So, block for 500ms, then drop into our loop.
	timer.start(core::time::Duration::from_millis(500));
	while timer.wait().is_err() {}

Then, build and load the example:

cargo objcopy --example pit --release --no-default-features -- -O ihex target/thumbv7em-none-eabihf/release/examples/pit.hex
teensy_loader_cli -w -v --mcu=TEENSY40 target/thumbv7em-none-eabihf/release/examples/pit.hex

Or, use this minimal example:

#![no_std]
#![no_main]

extern crate panic_halt;

use cortex_m::asm::wfi;
use teensy4_bsp::rt::entry;

#[entry]
fn main() -> ! {
    loop {
        wfi();
    }
}

Expected behavior
When main() is called, you can immediately WFI without issues. You can re-program the Teensy with the same example, and it works as expected.

Additional context
Work arounds:

• Add a wait, as shown in the pit.rs example. A few hundreds of milliseconds seems to be OK. Or, add a busy-loop, as shown in the RTIC examples:

  teensy4-rs/examples/rtic_uart_log.rs

  Lines 143 to 152 in b9f297e

  	// If we reach WFI on teensy 4.0 too quickly it seems to halt. Here we wait a short while in `init`
  	// to avoid this issue. The issue only appears to occur when rebooting the device (via the button),
  	// however there appears to be no issue when power cycling the device.
  	//
  	// TODO: Investigate exactly why this appears to be necessary.
  	fn init_delay() {
  	for _ in 0..10_000_000 {
  	core::sync::atomic::spin_loop_hint();
  	}
  	}

• Power-cycle the Teensy after reprogramming it. There's no issue when booting from a cold start.

You might not notice this when using the Teensy core libraries, since there's a 300ms delay before calling main(). We could introduce a similar workaround in the runtime crate.

[mciantyre]

Previous discussions in #64.

[ergpopler]

I am having this issue when trying to do the instructions on the readme, i cannot get it to work at all!

[mciantyre]

Thanks for the feedback. I updated the example in the template project so it won't be the first thing new users hit.

Did any of the workarounds described in the issue help?

[ergpopler]

Yes, when I put in the workaround and compiled it didn't update in my teensy loader, that was my bad.

[mciantyre]

No problem! Good to know a manual workaround helped.

I'm exploring a software workaround in #79.

[mciantyre]

There's a workaround on the main branch. Leaving this open as my reminder to document the behavior in the runtime crate.