search

dfu-rs / cargo-dfu

cargo extension for flashing embedded rust programs via dfu based on jacobrosenthals cargo-hf2
MIT License
16 stars 5 forks source link

can not dfu gd32vf103 #7

Closed xpulabs closed 1 year ago

xpulabs commented 1 year ago

hello,

as below:

cargo dfu --chip gd32vf103 --example hello
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
    Searching for a connected gd32vf103.
    Found  GigaDevice GD32 USB DFU in FS Mode
    Flashing "/data/programming/rust/embedded/polos_gd32vf/polos-alef/target/riscv32imac-unknown-none-elf/debug/examples/hello"
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Dfu(StatusError(ErrUnknown))', /home/alb/.cargo/registry/src/mirrors.ustc.edu.cn-61ef6e0cd06fb9b8/cargo-dfu-0.1.1/src/utils.rs:67:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I want to flash a bin file like hello.bin, I use:

cargo dfu --bin hello_pb9.bin --chip gd32vf103
error: no bin target named `hello_pb9.bin`

but I use dfu-util is Ok

dfu-util -a 0 -s 0x08000000:leave -D hello_pb9.bin 
dfu-util 0.11-dev

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 28e9:0189
Device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was
Clearing status
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Found GD32VF103, which reports a bad page size and count for its internal memory.
Fixed layout based on part number: page size 1024, count 128.
Downloading element to address = 0x08000000, size = 8816
Erase       [=========================] 100%         8816 bytes
Erase    done.
Download    [=========================] 100%         8816 bytes
Download done.
File downloaded successfully
Submitting leave request...
gnxlxnxx commented 1 year ago

Oh, well, I thought the gd32vf103 would work, but I know that chip does weird stuff. I will definitely look into it, but IIRC it might help to run twice.

I mean even in the dfu-util output you can see this:

DFU state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was Clearing status

It might also be worth a shot to try a commit before the move to dfu-libusb (eg. 6b79d67ff8099adc49373cf493094c9513162778) because as I wrote I think I remember doing something about exactly that problem.

cecton commented 1 year ago

It sounds familiar indeed.

If I recall, the device status should be cleared optionally if the device is already in error status. You can see that's what dfu-util does.

Determining device status... DFU state(10) = dfuERROR, status(14) = Something went wrong, but the device does not know what it was Clearing status Determining device status... DFU state(2) = dfuIDLE, status(0) = No error condition is present

Looking at the code, that's what dfu-core does already: https://github.com/dfu-rs/dfu-core/blob/main/src/get_status.rs#L132

It might give some useful information if you can enable the trace logs.