Thanks Tormod and Harald!
I found the problem. The problem was I was trying to send .hex via dfu-util and not .bin. Maybe we should try to probe .hex files and generate a warning as such obvious mistakes are easy to make. The other issue with reattaching the USB to the host disappeared as well.
Best regards,
-- Alex
On 8/13/24 12:25, Tormod Volden wrote:
On Tue, Aug 13, 2024 at 2:52 AM Alexander Feldman wrote:
- I check dfu-util:
Found Runtime: [2fe3:0005] ver=0306, devnum=117, cfg=1, intf=0, path="3-3.4.3", alt=0, name="UNKNOWN", serial="4327BC869F6C049C"
Notice there is only alt=0
Yes, in Run-Time mode there can only be one DFU interface, thus with alt=0.
The dfu-util -a filter option will only apply to DFU Mode interfaces. If you specify the correct -a value you should be able to do this with a single invocation of dfu-util.
I try to download the new image:
~/zephyr/counter/build/zephyr# dfu-util --download zephyr.signed.hex
The download fails but alt=1 appears:
Out of curiosity, what does dfu-util --list report at this stage, with the device in DFU mode?
I try to download the new image in the newly appeared slot:
~/zephyr/counter/build/zephyr# dfu-util --download zephyr.signed.hex --alt 1
Are you sure the bootloader expects a .hex file? It is possible that the bootloader receives the whole payload, says thanks and bye to dfu-util, for then to take a look at the payload and decides to ignore it.
Tormod _______________________________________________ dfu-util mailing list -- dfu-util@lists.osmocom.org To unsubscribe send an email to dfu-util-leave@lists.osmocom.org