Getting 504 error after flashing the newest micro:bit firmware

[RandyCHS]

I'm trying to use this extension with VSCode. After running the micro:bit-python: Flash MicroPython environment on micro:bit command, the yellow led on the back of the micro:bit flashes for several seconds. Then I get the sad face icon follow by the 504 error code. I also get an Error: Cannot connect to REPL output in VSCode afterwards if I try to flash a sketch.

[makinteract]

Thanks for the feedback. Could you please let me know what micro:bit version you are using? Can you identify the version of your board and, if you are using v2, the appropriate firmware you need (see the firmwares here)? Thank you for the help!

As a side note, if you are in a rush and just need it to work right away, consider uploading the firmware manually by downloading the right one using the link above. You just need to upload it once. Hope it helps...

[RandyCHS]

@makinteract Thanks for the quick response. I'm using a V2.21 micro:bit and this firmware (Build ID: v0257-gc782a5ba). However, I found a workaround based on a comment in this issue: Can not use audio.SoundEffect. If I flash a program using the MicroPython Editor, then I can use this extension with VSCode to flash other programs. So I'm good for now, but I'm happy to try out any other solutions you have for flashing the firmware from this extension in future.
Also, I'd like to be able to access the REPL for the micro:bit in the VSCode terminal; is that possible with this extension?

[makinteract]

@RandyCHS Thanks for the input. I do not have at the moment a V2.21 for test and debugging, but I'll purchase one and try to fix the bug. It won't happen overnight though. Sorry about the inconvenience and the need for a workaround in the meantime.

The extension does not grant access to the REPL directly, but when I was teaching with the micro:bit, I would use another extension in tandem with this one to access the REPL. I used to recommend the Serial Port Helper but I think that now you have official Microsoft support with the Serial Monitor. I would go for the latter. I also take this as a suggestion for the next update - I could probably easily add a command to open the REPL directly within the extension by wrapping the Serial Monitor interface... it should be trivial. It goes in my TODO list and, again, it won't happen overnight. Sorry.

[RandyCHS]

@makinteract Thanks again for the suggestion about Serial Port Helper. It works like a charm and even allows me to open REPLs to multiple attached (2 so far) micro:bits. Speaking of multiple ports, is there any way to set to preferred port when using your extension to interact with multiple micro:bits?

[makinteract]

There is no way to set a preferred port now, but again probably easy to implement... sorry

[martinwork]

Hi @makinteract A couple of support tickets about this have been raised with The Micro:bit Foundation. The suggested workaround seems OK. I'm a novice with VS Code extensions, but I hope the following might help...

The flashing code works for me in a simple node app, or when I run a clone of this repo in the debugger, and in a new simple extension project installed via a VSIX. I wonder if the problem lies in one of the extension's dependencies?

When it fails, the computer seems to stop sending the hex too soon (the LED stops flashing). The V1/V2 difference may simply be related to the fact the the V1 code is first in the hex.

With a variation like below edited into the installed extension.js, an error is detected if I disconnect the USB while it's flashing, but not if I let it stop on its own.

    vscode.window.showInformationMessage('Firmware upload started...');
    fs.copyFile(
      firmware.fsPath,
      vscode.Uri.joinPath(microbitUri, 'firmware.hex').fsPath,
      (err) => {
        if ( err) {
          console.log(err);
          vscode.window.showErrorMessage('Firmware upload failed');
      } else {
          vscode.window.showInformationMessage('Firmware uploaded');
        }
    });

[makinteract]

My understanding is that we could use a Universal Hex file. I believe I tried this approach a few times, but I was not able to get it to work correctly. It also adds to the complexity that there are multiple firmwares for V2 (here) — so one needs to pick between V1 and multiple V2 options. To solve this problem, I am leaning toward the option of asking users which version they want to install and letting users decide.

[martinwork]

@makinteract I think this may be the answer... The installed extension firmware.hex file line separators are CRLF instead of the usual LF. Dragging that file to a V2 MICROBIT drive also triggers 504 after about 20s or so. I wish I had tried this test first!

The raw file downloaded from https://github.com/makinteract/vscode-microbit-micropython/blob/main/firmware.hex is smaller by exactly number-of-lines bytes because its line separators are LF only.

If I replace the installed extension firmware.hex with the repo download version (both are universal hex files), the flashing command starts working. In tests I still sometimes saw 504, which is odd. Maybe because VS Code is caching the hex? Or maybe I was confused!

To be clear, the python runtime programs in this firmware.hex file run on the micro:bit main target processor, while the program in each firmware file available at https://microbit.org/get-started/user-guide/firmware/ runs on the micro:bit USB interface processor, and mostly just manages the USB connection and the LEDs on the back. The python runtime needs to be transferred each time you switch to python from another activity, while the interface firmware usually needs to be changed only when there is an update.
https://tech.microbit.org/hardware/#hardware-block-diagram

[makinteract]

Thank you @martinwork. This makes sense, and what a newbie mistake I made! I will follow your suggestion and exchange firmware.hex!

[martinwork]

@makinteract Yes, I can see your README points to the source of the python runtime universal hex. I know only too well how easy it is to forget the boring details after working on something else for a while!

For anyone arriving here via a search... micro:bit hex files should have LF only line endings. When cloning a GitHub repo that contains a micro:bit hex file, consider configuring git (at least on Windows) not to add CR to the line endings. The latest micro:bit micropython runtimes for V1 and V2 can be found by clicking the GitHub icons in the ?/About box of the Python Editor https://python.microbit.org/. There is the Universal Hex Creator for combining V1 and V2 files, and a splitter tool for the reverse. Those tools create LF only output, but will accept a CRLF file input.

[orioha]

same problem here , installed the microsoft serial monitor but not sure how to use it with the addon
what is the actual solution?

[makinteract]

Closing up on this. It took me a while, but I think that with version 0.1.34 of the extension, I have addressed the two issues in this thread.

1. First of all, I think I have addressed the problem with the firmware. I reverted to my former solution of using uflash as a dependency for flashing the firmware on the micro:bit. This seems to work for me well.

2. I have added support for the REPL using the official Serial Monitor extension (now a dependency). The user can then command Open the REPL, and it will be prompted with a list of available ports, and when selected, will open the port. Remember that you cannot have both this port open and flash your code on the micro:bit, so when you flash it, you need to disconnect the serial by stopping the monitoring.

I am marking this issue as solved. Thank you all.