Hi,

great tool for the mircobit! I just was wondering, if you could make the script exit with a non-zero exit code in case an error occurred.
E.g. at the point where the exeption is printed a following "exit(1)" would help to determin from e.g. a shell script if all worked or not.

Regards,
Stefan

Currently uFlash hexelifies by adding an “extended linear address record type" entry right before the python script starts. The unhexlify function relays on this entry to be immediately before the script, which might not be explicitly declared a second time if the hex file was created or extracted using different methods.

For testing purposes I am attaching a hex file where the data between start of address 0003xxxx and 0x0003e000 is present as such, without a double :020000040003F7 entry:
ubit_flash.txt (just rename from txt to hex).

i've just installed uflash with command sudo -H pip3 install uflash although it appears to have successfully installed i get the error output

Building wheels for collected packages: uflash
  Running setup.py bdist_wheel for uflash ... error
  Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-ied4gn_o/uflash/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmp2uvtutdcpip-wheel- --python-tag cp36:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help
  
  error: invalid command 'bdist_wheel'
  
  ----------------------------------------
  Failed building wheel for uflash

One for @bennuttall perhaps..? Apart from Python 3, there are no further requirements.

See the documentation here:

http://uflash.readthedocs.org/en/latest/

This would be really useful since it will allow people to use whatever editor they like to create MicroPython scripts.

I'd like to build it form source if possible.

Thanks

The py2hex tool that is described seems to be missing. I see the function in uflash.py, but one still has to add something trivial like

py2hex.py:
--->>---
import uflash
import sys
if name == 'main':
uflash.py2hex(sys.argv[1:])
---<<----

or am I missing some trick here?

I don't know whether this is possible from the tool, but having the Microbit automatically reset after flashing a new script would be great.

There's a pseudo file on the mounted drive called "HARD_RST.CFG" vs. "AUTO_RST.CFG" which can be used to set this directly on the Microbit, but it only works by going into maintenance mode first (https://www.mbed.com/en/development/hardware/prototyping-production/daplink/daplink-on-kl26z/).

The file mentions sending a "send a serial break command" would have the same effect. Perhaps the tool could do this via the COM port.

uFlash 1.0.8 appears to be incorrectly appending scripts to a runtime that I'm supplying which is based on the latest commit (f682113) of MicroPython.

• I have compiled an unmodified runtime of MicroPython using the above referenced commit.
• Flashing my runtime to the device without a script and carrying out some brief tests suggests that it's working properly - E.G. display, buttons, speech and radio all work.
• Using uFlash to flash any script and supplying my runtime results in the device seemingly doing nothing. The script is not executed, nothing is printed to serial & I am unable to access the REPL.
• Using uFlash to flash a script without specifying a runtime works.
• Using uFlash to flash a script using an older runtime such as https://github.com/ntoll/microrepl/blob/master/firmware.hex works.
• If I flash my runtime, rename my script to main.py and "put" it on the device using microfs it works - E.G. the script executes on boot, behaves as I would expect it to & I'm able to access the REPL.

mp.zip

Please see attached for my runtime. For what it's worth it was compiled under Windows 10 X64 which I realize might not be a typical build environment.
Apologies if the issue in fact turns out to be related to my runtime as opposed to uFlash.

This is my shell script to run the files simultaneously. bright.py file is imported in resistance.py. However, I get an import error that there is no such module bright. What could be the problem?

COMMAND1="uflash resistance.py" 
COMMAND2="uflash bright.py"
$COMMAND2 & $COMMAND1 &

There's an issue raised in microbit micropython repository and I think I've encountered something similar. A servo driver I wrote is now pointing all over the place.

Problem

Perhaps the best example of the issue is an LED. I used the following script:

Code

from microbit import pin0, sleep, display

display.scroll("1")

for i in range(0, 1023, 10):
    pin0.write_analog(i)
    sleep(100)


display.scroll("2")

pin0.set_analog_period(5)
for i in range(0, 1023, 10):
    pin0.write_analog(i)
    sleep(100)

Video

there's a video of it here.

Both flicker but the first is slightly worse.

Reproduced in

(all examples below return >>> MicroPython v1.7-9-gbe020eb on 2016-04-18; micro:bit with nRF51822 as their version)

Reproduced in:

• microbit.org.uk editor
• mu-2016-07-03_19_19_01
• mu-2016-07-31_23_01_47.exe
• mu-2016-08-13_20_40_52.exe
• mu-2016-10-15_13_20_00.exe
• mu-2016-11-14_08_54_40.exe
• mu-2016-12-23_14_19_21.exe
• current version of uflash.

Not Reproduced in:

• microbit.co.uk editor
• mu-2016-05-04-07-19-54.exe
• mu-2016-06-23_18_11_29.exe
• mu-2016-06-27_05_46_19.exe

Thoughts

It stops working between two sequential windows builds listed on the amazon cloud: 27-06-2016 and 03-07-2016.

Perhaps this commit in mu? and this one in uflash?. The runtime was updated.

.hex files flashed in the current version of uflash still flicker. I can checkout old versions of uflash but I cannot get it to flash a .hex. Not sure why.

There was an issue with PWM weirdness when they introduced to speech module. Perhaps that?

@ntoll FYI

Looks like the latest release in PyPI is 2.0.0, which has an old version of MicroPython for micro:bit V2.

v2.1.0 for micro:bit V2 and v1.1.0 for micro:bit V1 have been released recently, so I can update uFlash to include these versions and we can release uFlash 2.1.0.

Currently finding a small issue encoding the filesystem in the V1 hex file, so I'll need to fix that before I can submit a PR. I'll see if I have some time tonight, otherwise I'll be busy until next week.

i have a copy of micobit v2.1.0.beta how do i make uflash use that hex file?

Whilst packaging uflash and the MicroPython firmware, I've been wondering whether there would be a (significant) performance penalty during flashing if the firmware was always read from the local hex file (and the firmware string dropped from the uflash.py file)?

In selfish terms of downstream packaging of uflash, having only one copy of the firmware - in a separate file - would make managing firmware updates very straightforward. In Debian we'd use the Debian-built version of the firmware. Keeping the duplicate copy as an embedded string in the source code not only doubles the size of the package but also creates extra work "injecting" the locally-built firmware back into the source code after each update.

Is performance known to be okay reading the firmware hex in from the local file? Have I missed something important as to why the string version of the firmware is necessary?

Hi! :)

My problem is that when I upload the firmware with uflash, and try to import the log module, I get this error:

>>> import log
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: no module named 'log'

However, some modules load with no problem, like import radio or import neopixel.

Am I doing something wrong? Thank you very much in advance!

At the moment it is basically doing an assert len(data) <= 0x2000.
There should be a useful error message coming back instead, so that other tools could rely on uFlash to deal with this case gracefully and be able to respond accordingly.
Perhaps even add a check_script_size() type of function ?

I was trying a test program. I plan to have a large file so thought i'd give it a dummy run.
if i flash my script like this uflash test_fs.py . When the script executes it crashes with OSError: 28.
When i flash a blank micropython.hex uflash then put my script as main.py ufs put test_fs.py main.py it executes ok.
Here's a copy of the program which crashes:
test_fs.py.txt

I'm currently doing it with inotifywait, but I think that it might be usefull as part of uflash itself, with additional command line flag.

while inotifywait -e modify my_script.py; do
    uflash my_script.py
done

(BTW, 👍 for the guidelines for contribution!)

Please tag releases to keep this repo in sync with PyPI's release versions of uflash

uflash needs a --port option to direct the process to the correct microbit when multiple microbits are plugged in. It also probably needs to mimic how ufs (microfs) selects a port. I have 2 microbits plugged in uflash flashes the first, where as ufs ls lists the contents of the second

Hi,

I am trying to flash a Python script but get the following error:

ushort format requires 0 <= number <= (0x7fff * 2 + 1)

What does this mean, please, and how do I get around it?
Many thanks,
Andrew.

Is this because I'm a linux user with a single \n terminating my .py file lines and your flashing \r\n? It is 288 lines long

There should be a flag (--minify and -m) that causes uflash to "minify" the Python script using various heuristics so it'll fit into the limited amount of memory available.

See: mu-editor/mu#385 for an example of what I mean.

Hi. I consider packaging uflash and uploading it into Debian. This might be easier with your help. Are you interested in helping out to make this happen?

I just started with a micro:bit and had issues to install mu, so I was happy to find uflash.
However, trying to test it with an expansion board results in module issues with "superbit". I found a hex file which probably includes this, but as far as I can see, the current uflash (2.0.0) doesn't support uploading a hex file.
Is there another tool to upload a hex file, or is there an alternative to install the module along with my python file?
Or should I just try to use an older version of uflash (which leaves the question open why -r has been deprecated).

Every time I run the tool, a popup dialog comes up saying something like "There's no disk in the drive. Please insert a disk into driver \Device\Hardware1\DR1" (translated from German). The dialog asks for [Cancel], [Repeat], [Continue]. Clicking on [Continue] let's flashing continue and the tool does write to the correct mounted drive.

Now that we have the radio module, there's an obvious need to flash multiple devices at once, when updating a microbit squadron with your new game.

Currently you can address non-default targets like uflash race.py /media/tom/MICROBIT1 but it would be nice to have:
uflash race.py /media/tom/MICROBIT /media/tom/MICROBIT1

This would allow shell expansions like:

$ uflash race.py /media/tom/MICROBIT*
or
$ uflash race.py /media/tom/MICROBIT{,1,2}

Happy to write the patch if there's agreement on this feature.

Plugged it in, it's blinking with the demo.
Buttons and sensors seems to work normally (as used in the demo).

Ran:

tw@tux:~/w$ virtualenv --python=python3 mipy-env
tw@tux:~/w$ . mipy-env/bin/activate
(mipy-env)tw@tux:~/w$ pip install uflash
Downloading/unpacking uflash
  http://localhost:3141/root/pypi/+simple/uflash/ uses an insecure transport scheme (http). Consider using https if localhost:3141 has it available
  Downloading uflash-1.0.3.tar.gz (273kB): 273kB downloaded
  Running setup.py (path:/home/tw/w/mipy-env/build/uflash/setup.py) egg_info for package uflash

Installing collected packages: uflash
  Running setup.py install for uflash

    Installing uflash script to /home/tw/w/mipy-env/bin
Successfully installed uflash
(mipy-env)tw@tux:~/w$ uflash
Unable to find micro:bit. Is it plugged in?

Ubuntu 16.04, Kernel 4.6.4, Python 3.5.1, USB3 Port (have no USB2).

I was trying some blocks and returned to micropython.
when i tried command uflash my-script.py i get error message
Error flashing pongo.py to microbit: Unable to find micro:bit. Is it plugged in?

solution
uflash my-script.py ~/Downloads
that creates a micropython.hex in ~/Downloads I just copied that using a GUI file manager to my microbit

but with this script now flashed to the micobit uflash my-script.py still fails

I got a microbit v2. I found that uflash cannot generate .hex for microbit v2.
Do you have any plan to update uflash?

Using this command:
uflash -r custom_runtime.hex my_script.py (1)
I've tried to flash microbit using a custom runtime hex file you I created instead of the built in hex.

Microbit gets flashed but does not run my script. At first I thought there's something wrong with my custom runtime hex file, but then I tried with bbcmicrobit/micropython.
I built the frimware hex following their documentation, tried to flash microbit uflash -r microbit-micropython.hex my_script.py (2), no results.

Finally my last attempt was to run the same command but this time using the already built in hex file.
uflash -r built-in.hex my_script.py (3), works like a charm.

I'm wondering the reasons behind (3) working and not (1) & (2). Is uflash capable of only embedding scripts with the already built in run time hex?

Is it possible for uflash to pull a runtime from a micro:bit, validate that it is a MicroPython runtime, and then reflash the device after inserting the desired Python scripts, or is the process write-only?

The reason for the query is that the MicroPython runtime, as built via yotta and distributed with uflash/Mu, is built partly (as far I can see following the yotta build dependency chain) from sources that include non-free code (https://github.com/ARMmbed/ble-nrf51822 for example). Please correct me if this is not the case.

If it were possible to pull the runtime off a device prior to flashing, it would mean that the firmware would not need to be distributed in the downstream packages of operating systems that only distribute Free Software.

The MIT-licensed uflash repository contains firmware.hex, and uflash.py contains a copy of the firmware, and is MIT-licensed per header. Can I check that this is compatible with the more restrictive licensing of some of the upstream source(s)?

(I note the separate issue discussing the provenance of the included firmware.hex file at #46).

It looks like the firmware of uflash is built from 24th Oct 2016 (correct me if I'm wrong!). There have been some important bug fixes since then (notably PWM) and it would be great to update the firmware to the latest (also in mu).

how we check .hex file burning completed in microbit? to run another .hex file
in my case I am running one .hex file and before completing its burring I run another .hex file so I got a error like microbit not connected check microbit .
so if we able to identify first burning is not completed to burn another hex file then i think it solve a problem

If my computer is plugged into two microbits, how do I know which serial port corresponds to which microbit device?Through VID PID?

Hi,

Please can you tell me where the baked-in default firmware.hex is from? (e.g. which branch or tag in the BBCMicroBit MicroPython repo)

Thanks
Wayne

Hey @funkyHat please add yourself in whatever way is comfortable for you in the AUTHORS file. :-)

This happend when i use uflash -r

Looks like you already have a travis script present, is there a reason not to enable it? https://travis-ci.org/ntoll/uflash/ or maybe I am not looking at the correct place?

Hi, I'm not sure if I am trying to use this right, but when I try to run uflash I get a Failed To Create Process error.

Any suggestions how I should fix this?

Is there a reason that 'uflash my_file.py' creates micropython.hex instead of my_file.hex? Would there be an objection to changing it or would it be preferable to add an option like '-k' and/or '--keepname'?
I would like the functionality to be able to pre-hexlify files (uflash my_file,py ./). I'll start looking at the code to see how this could be done.

What it says on the tin.

At present, uflash relies on the setuptools console entry points mechanism via setup.py, which means you can't just do "uflash.py args" even though it's just one module!

I have got this error on Ubuntu 20.04 LTS and Windows 10 muti-time already when ever time I atemp to run "uflash -e xxx.hex xx.py".
Here is one of the HEX file that I trynna to transform to .py.
Qtruck-A.zip

Because sometimes, you don't save the source file... ;-)