Not sure if this is your problem or not, but a careful reading of the Windows update
procedure reveals that the DSO disconnects, changes it’s file system (.hex to .rdy) and
then reconnects. That kind of behavior is un-disk-like, and a race condition with the Linux VFS.
The fix I found for myself is to
rename the hex file to ALL CAPITALS - that is, app3.hex --> APP3.HEX
execute the mount/cp/umount really fast, i.e.:
mount -t vfat /dev/sdb /mnt/dso; cp FILENAME.HEX /mnt/dso; umount /dev/sdb
I had been completely unsuccessful at doing a DSO upgrade before I tried this and now it works
great just about every time. Note that this is not a true “fix”, but really just a workaround
so that the VFS unmounts the DSO before any evil has time to occur. It may or may
not work every time, but it worked for me.
I tried the APP3.HEX file pointed to above, and without the rename/gofast, it failed. Doing
it, it worked (well, it’s the same GUI as before, but it’s the gnu toolchain version).
Now it’s time to hack.