(System: Windows 10)
I was having problems flashing my micro:bit, so attempted it with a very simple program:
from microbit import *
while True:
display.show("1")
Flash failed.
Here are the logs for this attempted flash:
2018-07-19 11:16:21,158 - mu.logic:842(save_tab_to_file) INFO: Saving script to: C:Usersalasdair.trenchmu_codetest.py
2018-07-19 11:16:21,158 - mu.logic:843(save_tab_to_file) DEBUG: from microbit import *
while True:
display.show("1")
2018-07-19 11:16:23,998 - mu.modes.microbit:239(flash) INFO: Preparing to flash script.
2018-07-19 11:16:23,998 - mu.modes.microbit:249(flash) DEBUG: Python script:
2018-07-19 11:16:23,998 - mu.modes.microbit:250(flash) DEBUG: b'from microbit import *nnwhile True:n display.show("1")'
2018-07-19 11:16:23,998 - mu.modes.microbit:297(flash) INFO: Path to micro:bit: E:
2018-07-19 11:16:24,000 - mu.modes.base:217(find_device) INFO: Found device on port: COM26
2018-07-19 11:16:24,000 - mu.modes.base:218(find_device) INFO: Serial number: 9900023432044E45005180150000001400000000CFCF28BD
2018-07-19 11:16:24,000 - mu.modes.microbit:302(flash) INFO: Serial port: COM26
2018-07-19 11:16:24,000 - mu.modes.microbit:303(flash) INFO: Device serial number: 9900023432044E45005180150000001400000000CFCF28BD
2018-07-19 11:16:24,001 - mu.modes.microbit:328(flash) INFO: Checking target device.
2018-07-19 11:16:25,217 - mu.modes.microbit:364(flash) WARNING: Could not detect version of MicroPython.
2018-07-19 11:16:25,218 - mu.modes.microbit:381(flash) INFO: Flashing new MicroPython runtime onto device
2018-07-19 11:16:34,514 - mu.modes.microbit:505(copy_main) INFO: Copying main.py onto device
2018-07-19 11:16:34,514 - mu.modes.microbit:515(copy_main) INFO: ["fd = open('main.py', 'wb')", 'f = fd.write', 'f(b'from microbit import *\n\nwhile True:\n display.show("1")')', 'fd.close()']
2018-07-19 11:16:35,631 - mu.modes.microbit:532(flash_failed) ERROR: Could not enter raw REPL.
2018-07-19 11:16:35,640 - mu.interface.main:701(show_message) DEBUG: There was a problem flashing the micro:bit.
2018-07-19 11:16:35,640 - mu.interface.main:702(show_message) DEBUG: Please do not disconnect the device until flashing has completed. Please check the logs for more information.
2018-07-19 11:16:42,462 - mu.logic:1039(show_admin) INFO: Showing logs from C:Usersalasdair.trenchAppDataLocalpythonmuLogsmu.log
I unplugged the micro:bit and clicked 'flash' again, folder select box appears. Reconnected micro:bit and located the micro:bit folder in the dialogue box. Flash proceeded as normal and no error message showed. However, the micro:bit display just scrolls: Sad face, 0, 5, 0 on repeat.
This happens every time I try to flash any program to any of the micro:bits I have.
This is a duplicate of the #568 -- it's a serial related problem. Please check your settings / setup relating to serial communication on your computer.
I've just tried to recreate this using exactly the code and steps you outline (as implied by the log -- thanks for attaching that). I'm afraid it all works for me which suggests there's something about your setup that's different and potentially causing the problem.
Until I know more about what that might be, there's nothing I can suggest. Any ideas..? Sorry. :-(
@ntoll Thanks for the reply, I really quite confused by it, as I've used Mu loads of times before in one of the beta versions and it always worked fine. I'll try some firmware and settings changes.
@AlasdairAtKitronik tell me about it. The final "big-ish" feature to land in the beta was some work requested by the micro:bit foundation -- the new serial based flash (rather than just copying the hex file to the device). The latter method is far more robust but very slow. The new method of flashing is well tested but relies on the underlying OS to do serial connections "nicely". As I'm sure you know, this sometimes doesn't happen and my guess is this may be the cause. The more information you can provide, the better. Thank you! ;-)
@ntoll Right, that makes a bit more sense about why I'm having problems at this point. I've updated to the latest firmware - same issue. Do you know how I can check the serial settings for my machine and Mu?
So Mu just relies on whatever the OS does. I'm not really that familiar with serial related settings and configuration for the micro:bit. Perhaps @carlosperate might be able to point you to a knowledge base article? Carlos?
@AlasdairAtKitronik I'm more worried about the 050 error displaying on the micro:bit, it's likely that the DAL is crashing and therefore cannot connect to the MicroPython raw REPL required to send the files.
This specific error happens when it tries to detect the accelerometer or magnetometer during initialisation and fails.
Do you have anything plugged into the I2C pins that could block comms?
Doh... I missed the DAL error code. This indicates it's not a Mu problem since the board itself is in some sort of a bad state (viz @carlosperate's comments about I2C). In which case this should be raised upstream with DAL or microbit-micropython. If you've nothing plugged into the board, do you have another board to test with? Maybe your original board is damaged?
(Just thinking out loud and trying to help in a hand wave-y sort of a way... sorry.)
@carlosperate Thanks for the message, that has cleared pretty much everything up. I couldn't find what the 050 error code meant before. The micro:bit I'm using is one of our dev test ones - the magnetometer blew off during some testing.
I have now tried with an undamaged micro:bit (sorry), and Mu is flashing fine.
Strangely, I can still upload hex files from Microsoft MakeCode to the damaged board without any issues though...?
@ntoll Thanks for your advice - it has helped to work this through! I can now use the 'Files' feature fine as well.
Aha... glad to hear we've got to the bottom of things! Hurrah. I especially like the line,
"the magnetometer blew off during some testing"
Blimey... what sort of tests do you do..? :-P

(I'll close this issue and run to the bunker as a result.)
;-)
Glad we figured out the issue!
Strangely, I can still upload hex files from Microsoft MakeCode to the damaged board without any issues though...?
Yes, the previous version of the DAL didn't detect issues in this area, so it continued calculating the compass heading with whatever data was reading from the I2C methods. Of course, this would mean that methods like "compass.get_heading()" would return incorrect data.
Future versions of MakeCode will also update the underlaying DAL and then the same error will happen in those builds.
Haha! It involved some poor soldering on my part and a too long unidentified burning smell...
@carlosperate OK, thanks for the info. I may have to retire those micro:bits
Most helpful comment
Aha... glad to hear we've got to the bottom of things! Hurrah. I especially like the line,
Blimey... what sort of tests do you do..? :-P
(I'll close this issue and run to the bunker as a result.)
;-)