Yes!? By deduction, I've found that as long as a power source is available to the QMX in "update mode" it apparently sits waiting to reboot after a successful file copy.? Removing power completely let's that process lapse.
That isn't what normally happens and isn't what's supposed to happen. As soon as the new firmware finished copying in and installing, the bootloader is supposed to jump straight into the application, booting up QMX in the new firmware version. This is always what's happened for me.?
I suspect the question is, how the bootloader knows that the firmware copy is finished. The problem is on the USB Mass Storage Class devices (which means, USB Flash drive, in this case) there is nothing that guarantees that the 512 byte disk sectors will be copied in ascending order of the file. Though any "normal" human writing PC software would have no reason to send things in strange orders. But I suspect there may be occasions when this doesn't happen. The bootloader is supposed to be able to cope with this by maintaining a "scoreboard" of which file sectors it expects to receive, and ricks off each sector as it gets it, so when it has filled the scoreboaed with ticks, if is supposed to know that the file copy is complete, then it can reboot into the QMX main application. But Windows (and probably Linux too) does caching of disk contents and all kinds of other things I don't understand. It might be sending some other sectors over the USB connection along with the file, and that could perhaps be confusing the scoreboarding, I don't know.?
Generally the bootloader is extremely minimalist. It does USB Device stack, fake FAT16 file system, I2C comms (EEPROM) 256-bit encryption/decryption, and the Flash write. All in 16 KBytes of program memory so as to maximize Flash remaining for the QMX (of 512 KBytes total). Additionally there isn't Flash space to waste on keeping a complete copy of the new firmware file, nor RAM space for that either. So decryption and Flash write has to take place in real time as the file copies in from the PC. And all the while, the bootloader must remain as simple and easy and reliable as possible because there is absolutely zero opportunity to roll out firmware updates to the bootloader, it's fixed in place in those chips for all time.?
So there's a lot going on in the bootloader, and perhaps it doesn't cater properly for every single possible thing a host PC can throw at it. We've already seen that Android tries to write files to a connected disk and this doesn't go well with QMX.?
In the end if power down and power up is necessary in a few cases after firmware update, it's not a huge big issue.?
73 Hans G0UPL
