Add windows support

[codytrey]

fixes #7

[jacobrosenthal]

Thanks man! Did you need any specific libusb install stuff for windows? I know were having linux issues currently.

[codytrey]

Everything but cargo-hf2 compiles file out of the box. I should have tested this earlier (but have no way of knowing if it's related, I don't have a non-windows machine to test with atm), cargo hf2 is panicking when trying to flash to an Adafruit IstyBitsy M4.

cargo hf2 output and backtrace (RUST_LOG=debug and RUST_BACKTRACE=full):

C:\Users\cbelcher\rust\rs-ecu>cargo hf2 --example dotstar --release
 DEBUG cargo_project > Project::query(path=\\?\C:\Users\cbelcher\rust\rs-ecu): root=\\?\C:\Users\cbelcher\rust\rs-ecu
 DEBUG cargo_project > workspace search: cwd=\\?\C:\Users\cbelcher\rust
   Compiling rs-ecu v0.1.0 (C:\Users\cbelcher\rust\rs-ecu)
    Finished release [optimized + debuginfo] target(s) in 1.83s
    Searching for a connected device with known vid/pid pair.
    Trying  Ok(Some("Adafruit Industries")) Ok(Some("ItsyBitsy M4 Express"))
    Flashing "\\\\?\\C:\\Users\\cbelcher\\rust\\rs-ecu\\target\\release\\examples\\dotstar"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Arguments', src\libcore\result.rs:1165:5
stack backtrace:
   0:     0x7ff6e2083bc9 - backtrace::backtrace::trace_unsynchronized
                               at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.40\src\backtrace\mod.rs:66
   1:     0x7ff6e2083bc9 - std::sys_common::backtrace::_print_fmt
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:77
   2:     0x7ff6e2083bc9 - std::sys_common::backtrace::_print::{{impl}}::fmt
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:61
   3:     0x7ff6e20a27eb - core::fmt::write
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libcore\fmt\mod.rs:1028
   4:     0x7ff6e207f264 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\io\mod.rs:1412
   5:     0x7ff6e2086519 - std::sys_common::backtrace::_print
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:65
   6:     0x7ff6e2086519 - std::sys_common::backtrace::print
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:50
   7:     0x7ff6e2086519 - std::panicking::default_hook::{{closure}}
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:188
   8:     0x7ff6e208616c - std::panicking::default_hook
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:205
   9:     0x7ff6e2086cdc - std::panicking::rust_panic_with_hook
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:464
  10:     0x7ff6e2086850 - std::panicking::continue_panic_fmt
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:373
  11:     0x7ff6e2086739 - std::panicking::rust_begin_panic
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:302
  12:     0x7ff6e209e7fd - core::panicking::panic_fmt
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libcore\panicking.rs:139
  13:     0x7ff6e209e8ff - core::result::unwrap_failed
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libcore\result.rs:1165
  14:     0x7ff6e1f58d7e - core::str::traits::<impl core::slice::SliceIndex<str> for core::ops::range::RangeFrom<usize>>::index::{{closure}}::h77395350b0d43f00
  15:     0x7ff6e1f43eb6 - failure::Fail::__private_get_type_id__::h358d27a8faaaef9f
  16:     0x7ff6e2086697 - std::rt::lang_start_internal::{{closure}}
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\rt.rs:48
  17:     0x7ff6e2086697 - std::panicking::try::do_call<closure-0,i32>
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:287
  18:     0x7ff6e2091752 - panic_unwind::__rust_maybe_catch_panic
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libpanic_unwind\lib.rs:78
  19:     0x7ff6e2086f02 - std::panicking::try
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:265
  20:     0x7ff6e2086f02 - std::panic::catch_unwind
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panic.rs:396
  21:     0x7ff6e2086f02 - std::rt::lang_start_internal
                               at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\rt.rs:47
  22:     0x7ff6e1f5b957 - main
  23:     0x7ff6e20a8944 - invoke_main
                               at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  24:     0x7ff6e20a8944 - __scrt_common_main_seh
                               at d:\agent\_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  25:     0x7ffd7d5f4034 - BaseThreadInitThunk
  26:     0x7ffd7e453691 - RtlUserThreadStart

Using the example code from the istybitsy m4 hal crate: https://github.com/atsamd-rs/atsamd/blob/master/boards/itsybitsy_m4/examples/dotstar.rs

[jacobrosenthal]

Well that tells something, your usb does seem to find the device which means that part works.

is this with RUST_BACKTRACE=1 Not the best You can try on nightly, they just gave much better backtraces I think, though not sure it helps here. Also try my logging by adding RUST_LOG=debug as well maybe thatll say where its failing RUST_LOG=debug RUST_BACKTRACE=1 cargo hf2 --example dotstar --release

Thanks for helping debug!

On Fri, Jan 10, 2020 at 12:21 PM Cody Belcher notifications@github.com wrote:

Everything but cargo-hf2 compiles file out of the box. I should have tested this earlier (but have no way of knowing if it's related, I don't have a non-windows machine to test with atm), cargo hf2 is panicking when trying to flash to an Adafruit IstyBitsy M4.

cargo hf2 output and backtrace (RUST_LOG=1 and RUST_BACKTRACE=full):

C:\Users\cbelcher\rust\rs-ecu>cargo hf2 --example dotstar --release DEBUG cargo_project > Project::query(path=\?\C:\Users\cbelcher\rust\rs-ecu): root=\?\C:\Users\cbelcher\rust\rs-ecu DEBUG cargo_project > workspace search: cwd=\?\C:\Users\cbelcher\rust Compiling rs-ecu v0.1.0 (C:\Users\cbelcher\rust\rs-ecu) Finished release [optimized + debuginfo] target(s) in 1.83s Searching for a connected device with known vid/pid pair. Trying Ok(Some("Adafruit Industries")) Ok(Some("ItsyBitsy M4 Express")) Flashing "\\?\C:\Users\cbelcher\rust\rs-ecu\target\release\examples\dotstar" thread 'main' panicked at 'called Result::unwrap() on an Err value: Arguments', src\libcore\result.rs:1165:5 stack backtrace: 0: 0x7ff6e2083bc9 - backtrace::backtrace::trace_unsynchronized at C:\Users\VssAdministrator.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.40\src\backtrace\mod.rs:66 1: 0x7ff6e2083bc9 - std::sys_common::backtrace::_print_fmt at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:77 2: 0x7ff6e2083bc9 - std::sys_common::backtrace::_print::{{impl}}::fmt at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:61 3: 0x7ff6e20a27eb - core::fmt::write at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libcore\fmt\mod.rs:1028 4: 0x7ff6e207f264 - std::io::Write::write_fmt at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\io\mod.rs:1412 5: 0x7ff6e2086519 - std::sys_common::backtrace::_print at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:65 6: 0x7ff6e2086519 - std::sys_common::backtrace::print at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\sys_common\backtrace.rs:50 7: 0x7ff6e2086519 - std::panicking::default_hook::{{closure}} at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:188 8: 0x7ff6e208616c - std::panicking::default_hook at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:205 9: 0x7ff6e2086cdc - std::panicking::rust_panic_with_hook at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:464 10: 0x7ff6e2086850 - std::panicking::continue_panic_fmt at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:373 11: 0x7ff6e2086739 - std::panicking::rust_begin_panic at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:302 12: 0x7ff6e209e7fd - core::panicking::panic_fmt at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libcore\panicking.rs:139 13: 0x7ff6e209e8ff - core::result::unwrap_failed at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libcore\result.rs:1165 14: 0x7ff6e1f58d7e - core::str::traits::<impl core::slice::SliceIndex for core::ops::range::RangeFrom>::index::{{closure}}::h77395350b0d43f00 15: 0x7ff6e1f43eb6 - failure::Fail::__private_get_type_id::h358d27a8faaaef9f 16: 0x7ff6e2086697 - std::rt::lang_start_internal::{{closure}} at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\rt.rs:48 17: 0x7ff6e2086697 - std::panicking::try::do_call<closure-0,i32> at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:287 18: 0x7ff6e2091752 - panic_unwind::rust_maybe_catch_panic at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libpanic_unwind\lib.rs:78 19: 0x7ff6e2086f02 - std::panicking::try at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panicking.rs:265 20: 0x7ff6e2086f02 - std::panic::catch_unwind at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\panic.rs:396 21: 0x7ff6e2086f02 - std::rt::lang_start_internal at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14\/src\libstd\rt.rs:47 22: 0x7ff6e1f5b957 - main 23: 0x7ff6e20a8944 - invoke_main at d:\agent_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 24: 0x7ff6e20a8944 - __scrt_common_main_seh at d:\agent_work\5\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 25: 0x7ffd7d5f4034 - BaseThreadInitThunk 26: 0x7ffd7e453691 - RtlUserThreadStart

Using the example code from the istybitsy m4 hal crate: https://github.com/atsamd-rs/atsamd/blob/master/boards/itsybitsy_m4/examples/dotstar.rs

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jacobrosenthal/hf2-rs/pull/8?email_source=notifications&email_token=AADPI5GDFT3GGBKXDYIVQLTQ5DDD3A5CNFSM4KFLOKJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIU6KGI#issuecomment-573170969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADPI5BHRZSLFUARFITVZ63Q5DDD3ANCNFSM4KFLOKJA .

[codytrey]

I'll test with nightly and update, but I think I may have found something and hoping you can verify.

Should I be able to create a new text file to the mounted "disk" when the board is in flashing mode? I get "Catastrophic failure" back from windows when I try. Thinking it could be security software interfering with removable devices.

[jacobrosenthal]

Yes. It should be mounted. Im not sure itll take a text file might just unmount because it doesnt know what it is. Take a look at bootloader instructions on here https://learn.adafruit.com/introducing-adafruit-itsybitsy-m4/uf2-bootloader-details

If you want to test writing to drive, Id create or just grab a prebuilt uf2 file, like the bootloader from here

Which links here https://github.com/adafruit/uf2-samdx1/releases/tag/v3.7.0

probably update-bootloader-arcade_itsybitsy_m4-v3.7.0.uf2 https://github.com/adafruit/uf2-samdx1/releases/download/v3.7.0/update-bootloader-arcade_itsybitsy_m4-v3.7.0.uf2 for you?

On Fri, Jan 10, 2020 at 1:08 PM Cody Belcher notifications@github.com wrote:

I'll test with nightly and update, but I think I may have found something and hoping you can verify.

Should I be able to create a new text file to the mounted "disk" when the board is in flashing mode? I get "Catastrophic failure" back from windows when I try. Thinking it could be security software interfering with removable devices.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jacobrosenthal/hf2-rs/pull/8?email_source=notifications&email_token=AADPI5DRMCPQJGUNBBZUFGDQ5DIVDA5CNFSM4KFLOKJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIVCGDA#issuecomment-573186828, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADPI5FHC6W2KJWCJBND2TTQ5DIVDANCNFSM4KFLOKJA .

[codytrey]

I tried to update the boot loader, but windows seems to think the device has write protection enabled. That seems to make sense with the backtrace from nightly. Error coming from when flash_elf is called:

C:\Users\cbelcher\rust\rs-ecu>cargo hf2 --example dotstar --release
 DEBUG cargo_project > Project::query(path=\\?\C:\Users\cbelcher\rust\rs-ecu): root=\\?\C:\Users\cbelcher\rust\rs-ecu
 DEBUG cargo_project > workspace search: cwd=\\?\C:\Users\cbelcher\rust
   Compiling rs-ecu v0.1.0 (C:\Users\cbelcher\rust\rs-ecu)
    Finished release [optimized + debuginfo] target(s) in 13.97s
    Searching for a connected device with known vid/pid pair.
    Trying  Ok(Some("Adafruit Industries")) Ok(Some("ItsyBitsy M4 Express"))
    Flashing "\\\\?\\C:\\Users\\cbelcher\\rust\\rs-ecu\\target\\release\\examples\\dotstar.exe"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Arguments', cargo-hf2\src\main.rs:159:5
stack backtrace:
   0:     0x7ff6885611e9 - backtrace::backtrace::trace_unsynchronized

where cargo-hf2\src\main.rs:159:5 is this line:

flash_elf(path, &d).unwrap();

https://github.com/codytrey/hf2-rs/blob/a3a27de8a18c54c9cbcb4c23bb77ba6145118618/cargo-hf2/src/main.rs#L148

[codytrey]

Was able to use a different machine to test updating the bootloader. Worked flawlessly on that machine that doesn't have the extra security software as my windows box.

I'll see if I can get time to install the rust tool chain on the other machine to verify the changes to cargo-hf2 and update with the results.

[codytrey]

Made some additional progress. The backtrace was actually caused when the built elf binary was attempted to be opened for reading. But for some reason, the default target from Cargo.toml isn't being used. Instead project.target() and opt.target.as_ref().map(|t| &**t) are both none.

I can of course override the later by passing --target thumbv7em-none-eabihf and I no longer get a backtrace. (But it does hang indefinitely, which I'll assume to be caused by ever annoying security software until I can test from a different windows box)

[jacobrosenthal]

My understanding is that this is still pending further testing for other incompatibilities, yes?

[codytrey]

I'm away from my computer at the moment so I can't find the issue to reference but I believe it should be marked upstream as I saw an open issue on the Microsoft uf2 bootloader that seemed to indicate a problem with the bootloader messaging as an HID device on windows.

On Tue, Jan 21, 2020, 4:28 PM Jacob Rosenthal notifications@github.com wrote:

My understanding is that this is still pending further testing for other incompatibilities, yes?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jacobrosenthal/hf2-rs/pull/8?email_source=notifications&email_token=AAHC3XF6XRQQCBXG5JTTQLLQ65ZKHA5CNFSM4KFLOKJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRQQ3Q#issuecomment-576915566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHC3XFMRNCVDDPKUZO5QFTQ65ZKHANCNFSM4KFLOKJA .

[elfmimi]

The patch proposed here is no good. There are OSs other than linux or windows. At least MacOS is mentioned in readme.md .

[jacobrosenthal]

Closed for #20