Panic in `aux5::init`

[paulkernfeld]

👋 Hi, I'm doing a small study group (with @mjhoy and @deffen3) and each of us encountered this issue when trying to do "debug it" in the LED roulette example:

(gdb) backtrace
#0  0x08003556 in rust_begin_unwind (_info=0x10001e78) at /Users/mjhoy/.cargo/registry/src/github.com-1ecc6299db9ec823/panic-halt-0.2.0/src/lib.rs:33
#1  0x0800316e in core::panicking::panic_fmt () at src/libcore/panicking.rs:111
#2  0x08003106 in core::panicking::panic () at src/libcore/panicking.rs:54
#3  0x08000332 in core::option::Option<T>::unwrap (self=core::option::Option::None)
   at /Users/mjhoy/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/src/rust/src/libcore/macros/mod.rs:34
#4  0x08000232 in aux5::init () at src/05-led-roulette/auxiliary/src/lib.rs:17
#5  0x0800019e in led_roulette::__cortex_m_rt_main () at src/05-led-roulette/src/main.rs:9
#6  0x08000190 in main () at src/05-led-roulette/src/main.rs:7

The content of lib.rs:17 is:

let cp = cortex_m::Peripherals::take().unwrap();

We were able to apparently fix it by changing the version of the cortex-m dependency from 0.5.6 to 0.6.3 in src/05-led-roulette/auxiliary/Cargo, but perhaps there is a better way to do it.

[therealprof]

Hm, take() is guarded by a singleton to protect multiple use. If the unwrap() failed that would suggest that someone has taken the peripherals before.

We probably should update the depedencies anyway, so it doesn't make too much sense spending time on why it fails in the old version. Maybe you'd like to make that change throughout and PR it?

[paulkernfeld]

After trying to bump the version of cortex-m in throughout the repo, the build failed (only in chapters 11 and 16, actually). I think this is because the f3 crate is still using cortex-m 0.5. I tried to update the f3 crate, but didn't get too far because it's currently broken (see https://github.com/japaric/f3/issues/110). There are a couple PRs that are attempting to fix that issue, so I think as soon as one of them is merged it should be possible to update this repo to cortex-m 0.6. Does that sound right?

[therealprof]

TBH this shouldn't be using f3 anymore, it is not being worked on and superceded by other efforts. https://github.com/rubberduck203/stm32f3-discovery could probably replace it, or we could integrate the relevant parts into the turtorial code and base it of stm32f3xx-hal directly.

Maybe we should ping @japaric here to discuss options.