Open microbit-carlos opened 3 years ago
As I understand, this is by design. DAPLink's drag-n-drop feature is not fine tracking sector allocation. so it can not distinguish to which file entry the stream corresponds. instead it's relying on file extension for some extent of certainty.
Thanks @elfmimi, I suspected it would be something like that. @mathias-arm / @flit if this is by design feel free to close this issue 👍
If a hex file without an extension is flashed the transfer times out and it generates a fail.txt file.
Example hex file without extension to replicate: microbit-house.zip
As it takes about a minute or so to time out you can see the file "still present" on the drive until it remounts, and during this time the programme is already running on the micro:bit as usual:
FAILT.TXT:
Tested with DAPLink 0254 for micro:bit V1. Details.txt:
The data itself is correctly written to flash, so this has not been a problem for micro:bit V1, but because V2 detects the DAPLink error it then flashes the small error programme to scroll the error code on the display and erases the user programme.
That being said, this is very low priority for micro:bit, as there are not many cases where a user would flash a hex file without an extension, and if they do is likely they are using advanced editors and/or developer tools.
Nevertheless I thought it's still worth raising in GitHub to let you know about this issue.