python-editor-v3 icon indicating copy to clipboard operation
python-editor-v3 copied to clipboard

[Serial] Initial serial output after connecting over WebUSB is lost

Open microbit-mark opened this issue 3 years ago • 6 comments

Bug Description

A clear and concise description of what the bug is.

Needs a repro. Not sure if this is a bug as I haven’t been able to reproduce as yet, but on a zoom call flashing this code via WebUSB produced an error on the device for line 6, but not in the editor.

image

How To Reproduce

  1. Connect via WebUSB
  2. Flash erroneous program to micro:bit
  3. See error on device but not in editor
  4. Repeat 2&3

We then fixed the code and flashed the device which works as expected, then introduced a different error (removing the colon : from while True and this errored as expected.

Expected behavior

Would expect error bar to show as with this example image

Environment

Desktop (please complete the following information):

  • OS: [e.g. iOS] Windows
  • Browser [e.g. chrome, safari] Chrome
  • Version [e.g. 22] 97

Additional context

Did not open the serial console to check to see if the error was present in the REPL.

microbit-mark avatar Jan 27 '22 15:01 microbit-mark

The most useful thing would be to see what the serial output was at that point. The serial area error highlighting works by pattern-matching the output, so if some of the output was missing that could be the cause.

microbit-matt-hillsdon avatar Jan 27 '22 15:01 microbit-matt-hillsdon

It's a known issue that the first few characters sent from the micro:bit are lost. We should consider whether we can work around this. See https://github.com/ARMmbed/DAPLink/issues/903

@microbit-carlos, @jaustin asks if there's a way to sidestep this issue without impact on a user program.

It's possible this isn't the cause of this issue but it seems like the thing to address first.

microbit-matt-hillsdon avatar Feb 02 '22 14:02 microbit-matt-hillsdon

@microbit-carlos, @jaustin asks if there's a way to sidestep this issue without impact on a user program.

As it currently stands @jaustin is still more familiar with this issue than I am, so I don't have an answer from the top of my head. If needed I would have to schedule some time aside to investigate, is there any timeline/deadline for this?

microbit-carlos avatar Feb 02 '22 15:02 microbit-carlos

I think it's possible to interrupt the micro:bit after connecting in order to generate some serial data for us to check this buffer is cleared.

One use-case we need to consider is the situation where the micro:bit has been used to collect data that needs to be exported over serial. After plugging the board in, we want to press button A to 'read out' our logged data. Things we do for this issue should not break that if possible.

jaustin avatar May 16 '22 09:05 jaustin

I think it's possible to interrupt the micro:bit after connecting in order to generate some serial data for us to check this buffer is cleared.

We can stop the user code from running by entering the REPL (Ctrl+c raising a KeyboardInterrupt exception), but I am not aware of a way to pause the programme where it could later be resumed where it left off.

One use-case we need to consider is the situation where the micro:bit has been used to collect data that needs to be exported over serial. After plugging the board in, we want to press button A to 'read out' our logged data. Things we do for this issue should not break that if possible.

Yes, with this in mind a way to avoid breaking this use case would be to, only before WebUSB flashing, we could send Ctrl + C commands to MicroPython until we read the expected data (we could try to match simply the last few bytes of the full string MicroPython prints to serial).

microbit-carlos avatar May 17 '22 10:05 microbit-carlos

Came up via support: https://support.microbit.org/a/tickets/56484 (private)

microbit-matt-hillsdon avatar Oct 04 '22 17:10 microbit-matt-hillsdon