Open marc0janssen opened 3 years ago
OK... this is something weird.
I can't explain this
Found out something new:
After a while the problem was back.
When I deleted the "main.py" in files from the MicroBit, I could flash again.
After uploading a HEX from makecode.. I run into the same problems again... can't flash python-source to the microbit
Can someone help me what I'm doing wrong?
Can you attach to this post (it might need to be on a zip file) the hex that caused a fail.txt? A copy of the fail.txt file and the details.txt file would be useful too.
The fail.txt will not always appear,... If it appears it is when I disconnect the microbit, then generate a HEX on disk. and copy this HEX by the hand on the microbit... then sometimes the fail.txt appears... at the moment is it not the case. If I have it, I will share.
Weird stuff is that I can't reflash the microbit unless I delete the main.py from the microbit
FAIL.TXT
error: In application programming failed because the update sent was incomplete.
type: interface
DETAILS.TXT
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 9904360258824e450031800200000048000000009796990b
HIC ID: 9796990b
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Incompatible image detection: 1
Page erasing: 0
Daplink Mode: Interface
Interface Version: 0255
Bootloader Version: 0255
Git SHA: 1436bdcc67029fdfc0ff03b73e12045bb6a9f272
Local Mods: 0
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0x828c6069
Interface CRC: 0x5b5cc0f5
Remount count: 5
URL: https://microbit.org/device/?id=9904&v=0255
Thanks @marc0janssen do you also have the hex that has caused this? That file would be really useful to debug this.
How I fixed it:
This fixed it for me...
Thanks @marc0janssen do you also have the hex that has caused this? That file would be really useful to debug this.
Sorry that was lost in the process and after the above procedure all is fine for me now...
The flash takes the aspected time now and the program runs,,,
(weird fact... with the problem there, if the occasional did work, the flash was really really short, compared to the normal flash)
Thanks for sharing that solution! it's really appreciated :)
Sorry that was lost in the process and after the above procedure all is fine for me now...
The flash takes the aspected time now and the program runs,,,
I think there might be two problem in this issue. One was the permission issue that has been solved by adding /bin/sh
to the security settings. The other seems to be that hex files generated by Mu might not be valid?
If that is the case I would expect the fail.txt issue might happen again in the future.
(weird fact... with the problem there, if the occasional did work, the flash was really really short, compared to the normal flash)
Yeah, based on the error looks like the file is not complete.
Hi Carlos.
That could be. But when the flashing was not working. In others words I hadn't added the sh to security, I could flash the program be removing the Main.py from the microbit and push the flash button.
That's also weird isn't it?
Right, generally the way that it works is that if Mu detects micro:bit already has MicroPython running on the device it will send the code via serial (serial works without adding the additional permissions to /bin/sh
).
The main problem happens when Mu has issues detecting if MicroPython is in device, at that point it tries to copy a micropython.hex file (with just MicroPython) into the MICROBIT drive, and then send the files via serial. Is in this case that the permission issue is triggered and caused problems.
When clicking the "Flash" button without the micro:bit plugged in, Mu will ask where to save a (specially generated) .hex file with MicroPython and the user code attached inside. This method is only used in special cases, as it has several disadvantages, but is still available.
If a generated hex file from Mu (with MicroPython and the user code) causes a fail.txt file in the micro:bit, it probably means there is a bug in the creation of this special hex file, which is why I was so interested to analyse one, and ideally get the Python source code as well to see if I could recreate the problem to debug it.
Btw, thanks again for all the testing and reports you've done, it's been incredibly useful!
Thanks explaining that!
The strange thing is:
If I haven't given /bin/sh full permissions, I can flash main.py (by the flash button) on the Micro:bit WHEN I delete the main.py that's on there already. If I don't delete it on forehand I get an error and it won't flash.
If I do give /bin/sh full permissions, I can ALWAYS flash the microbit BUT it's also ALWAYS a full HEX-flash, even though Micropython has been flashed on the Microbit in a previous flash.
(No worries on helping you guys... If I can help in anyway, I would like to do so.)
I can't seem to flash a microbit V2 with MU-editor.