microbit-foundation / micropython-microbit-v2

Temporary home for MicroPython for micro:bit v2 as we stablise it before pushing upstream
MIT License
43 stars 24 forks source link

Downloading beta1 error to the device gives error: The transfer timed out #38

Closed aivarannamaa closed 3 years ago

aivarannamaa commented 3 years ago

I'm implementing micro:bit firmware updater for Thonny IDE.

Thonny reads https://github.com/microbit-foundation/micropython-microbit-v2/releases/download/v2.0.0-beta.1/micropython-microbit-v2.0.0-beta.1.hex in blocks of 8KB and writes each block to the target volume before reading the next block.

In order to support faithful progress indicator, it also does target_file.flush() and os.fsync(target_file.fileno()) after each block (othewrise the progress bar rushes to 100% and gets stuck there for many seconds until the buffer is written to micro:bit).

With micro:bit v1.3 this approach worked without problems, but with v2.0 things get strange. The process completes as expected, (I can even connect to MicroPython REPL), but MICROBIT volume does not disappear and reappear. The target file remains visible.

After about 10 seconds, the volume disappears and reappears with FAIL.TXT containing

error: The transfer timed out.
type: transient, user

The display shows sad face and 405 and MicroPython REPL is not accessible until I do the same procedure again, but then I can use it again only for a few seconds.

It looks like some part does not understand that copying the firmware has finished (I believe the file does get closed -- I'm opening the file for writing with with).

I tried without os.fsync(target_file.fileno()), but the problem remained.

aivarannamaa commented 3 years ago

Forgot to add, that all this happened on Ubuntu 20.04.

I now tried unmounting the device manually before the timeout, but the result was the same.

Tried also pre-downloading the whole firmware, but this didn't help either.

This is the DETAILS.TXT of my device:

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 9904360249624e450044601500000066000000009796990b
HIC ID: 9796990b
Auto Reset: 1
Automation allowed: 0
Overflow detection: 0
Incompatible image detection: 1
Page erasing: 0
Daplink Mode: Interface
Interface Version: 0254
Bootloader Version: 0254
Git SHA: ec3fec91e815b1fe27cefb8bc4ffa85ca3317502
Local Mods: 0
USB Interfaces: MSD, CDC, HID, WebUSB
Bootloader CRC: 0xdb256cca
Interface CRC: 0xd0f0bacf
Remount count: 0
URL: https://microbit.org/device/?id=9904&v=0254
aivarannamaa commented 3 years ago

I found something that made a difference -- if I'm using ".hex" suffix for the target filename, then everything works.

If this is by design, then please close this issue.

microbit-carlos commented 3 years ago

Thanks for the report Aivar, this would be an issue with DAPLink, the firmware running on the USB interface chip, but we can discuss this here before opening an issue upstream.

We noticed there were file timeouts when transferring a file without extension, but we didn't realised this was not an issue with V1, I thought it was a problem in all DAPLink versions.

Could you try this version of DAPLink in your v1 and see if it has the same problem? 0254_kl26z_microbit_0x8000.hex.zip

After doing that test I'd probably recommend going back to version 0249 that can be downloaded from https://tech.microbit.org/software/daplink-interface/.

aivarannamaa commented 3 years ago

I tried different bootloaders on my v1.3 -- 0254, 0249, 0241 and 0234. Only 0234 was fine with firmware without .hex suffix.

Unfortunately I was too quick to install new bootloader and I forgot to take note of what I had before. I can only tell that it was not 0234, because this one has very different DETAILS.TXT (only 3 lines).

aivarannamaa commented 3 years ago

0254, 0249, 0241 and 0234

Just in case -- these numbers I took from the interface column, not from the bootloader column (https://tech.microbit.org/software/daplink-interface/)

microbit-carlos commented 3 years ago

Unfortunately I was too quick to install new bootloader and I forgot to take note of what I had before. I can only tell that it was not 0234, because this one has very different DETAILS.TXT (only 3 lines).

Yeah 0234 is quite old, and there were some significant changes from that to 0241. But it's a bit odd your original DAPLink version didn't show this problem if it wasn't 0234, that's the only version with the tiny details.txt. There wasn't really any DAPLink releases distributed or shared between 0234 and 0241 (well, technically they were posted in the DAPLink repository, but you'd have to download a zip file with all the targets and find the micro:bit version). If it doesn't work in versions 0254, 0249, and 0241 I'd expect the problem to persist in any of the in-between versions. Just for background info, these are the factory versions: v1.3: 0234 v1.3B: 0241 v1.5: 0249 v2: 0255

Just in case -- these numbers I took from the interface column, not from the bootloader column (https://tech.microbit.org/software/daplink-interface/)

Yes, good point. Technically the bootloader would be really hard to update without a programmer, so that should always stay in the same version, these files update only the DAPLink Interface. Nevertheless the bootloade shouldn't really affect the Interface operation once it is running.

Were you able to resolve this issue in Thonny?

aivarannamaa commented 3 years ago

Were you able to resolve this issue in Thonny?

Yes, when I added .hex suffix to the target file, everything works fine. I'm happy to close this issue if there is nothing to be done for you.

If you're interested, then you can see the result in the latest Thonny release:

microbit-carlos commented 3 years ago

Just gave that a spin and works great!

Have the extension issue tracked in a different place (although we didn't realised it was also a problem with older DAPLink versions), so I'll close this one here since it's not that related to MicroPython.

Thanks Aivar for all your help with the debugging!