20 Aug
2024
20 Aug
'24
1:54 a.m.
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:
4. 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.
5. 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?
6. 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(a)lists.osmocom.org
To unsubscribe send an email to dfu-util-leave(a)lists.osmocom.org