VER: 0.3.3, released on January 4, 2019 will not start without a micro:bit in a USB port

[Turgut Guneysu]

Hi John

As mentioned in the title, it will not start without a device in the USB port.

The Command com window opens up and displays “SDL2 headers: 2.0.7; lib: 2.0.7” and stops.

The program WINDOW opens up blank with “not responding” showing in the title:

‌

Once in this state, it will NOT recover when the micro:bit is plugged into the USB.

ALSO:

With micro:bit plugged into the USB, the program starts OK. However, when the micro:bit is disconnected

it displays:

‌

on the command.com window and the main program window displays:

‌

in faded colors and it HANGS and never recovers when micro:bit is plugged back in.

Previous version was starting without a device plugged in, as well as running without a problem throughout any device disconnects.

‌

[John Maloney]

Strange. I can’t reproduce either of these behaviors on Windows 10. It sounds like your serial port hardware may have gotten into a strange state. Does shutting down and restarting help?

What version of Windows are you running? Do you update it frequently? (It’s possible that a recent Microsoft update changed something about how serial ports work. Since I don’t run Windows every day, I tend to be behind on updates which could explain why it works on my computer and not on yours.)

If power-cycling doesn’t fix the problem, you can get the previous version here.

[Turgut Guneysu]

I'm running WIN10 Home Edition with all patches up to date.

Power down and restart did not change anything.

Unless micro:bit is plugged in at program start time, it is totally unusable.

I guess you need feedback from some other Win10 users.

In the meantime, I will revert to the previous version and continue.

QUESTION:

Is there a way I can tell what has been changed in a particular release?

I did not see a per release bugs corrected / features implemented type of list. The one here where we report things does not indicate something is fixed or not, unless you mention it in the descriptions. Could the STATUS field used for that?

[John Maloney]

The release notes for each release are on the releases page:

https://github.com/bromagosa/microblocks-site/releases

I don’t know of any changes between 0.3.2 and 0.3.3 that might have caused this issue. Please let me know if reverting to 0.3.2 fixes the problem, since that will at least limit the set of changes that could have introduced this bug.

When you downgrade the IDE, try connecting with the new (v73) VM installed on your micro:bit (assuming you installed that). It would be helpful to know if the issue is with the the IDE or the VM. It’s probably the VM, since there were were no significant IDE changes between 0.3.2 and 0.3.3, but it would be good to know for sure.

I will make sure my Window 10 has the latest updates in case a recent Windows update introduced the problem.

[John Maloney]

Hi, Turgut. I could not reproduce this problem running 0.3.3 (with VM v73) on a Lenovo Thinkpad at my local library running Windows 10 Enterprise.

Any news from your end? Did reverting to v0.3.2 fix the problem for you?

[John Maloney]

I’ve also updated my own PC with the latest Microsoft updates. MicroBlocks 0.3.3 starts up even when there isn’t a micro:bit plugged in.

Do you have any other devices connected to your computer that look like serial ports (e.g. a Bluetooth dongle)? If so, try unplugging them. It’s possible that MicroBlocks is trying to open them as if they were a micro:bit and getting hung up. That can sometimes happen if you have drivers for such devices installed even when the device itself isn’t connected. You can check the “Ports (COM and LPT)” section in the Windows “Device Manager” to see if you have any such devices.

[Turgut Guneysu]

Hi John

Sorry for late response. It took me a while to test everything. Here is what I have found out:

The problem seems to be BLUETOOTH related. At least on my machine:

When BT is enabled, it will enumerate a “Standard Serial Over BT Link” with a COM port number almost always lower than the other existing COM ports.

micro:bit when plugged in, in my system, enumerates a “mbed Serial Port (COM4)”.

If I start microBlokcs with BT enabled, it seems to want to go to the first listed COM port and gets hung up on BT port, since there is no firmware reply there (my assumption, of course).

With BT DISABLED, no problems, since the BT COM port gets deleted by the system.

I tried tricking the microBlocks by renaming the BT COM port to a higher number than the microBlocks mbed Serial port. However, that does not work, probably because renaming it does not change its enumeration order in the system, and a such it is still appearing as the first COM port and locks up microBlocks.

Also, one new behavior I noticed with the new release is the command.com window display upon program start (not related to BT):

• before it used to come up and display the SDL Header info, followed by the “connected to COMn” message and then “All tasks stopped” .
• With the new release, if micro:bit is plugged in, it displays the SDL header and then lists a very long sequence of “Could not open Serial port” messages - maybe over a hundred lines or so. This is followed by the normal “Connected to COMn” and “All tasks stopped”. Now the normal operation starts, until I UNPLUG the USB cable and the display starts showing the “Could not open Serial port” messages. At this point, if I CLICK on the command.com window, then the program locks up as described below.
• With the new release, if micro:bit is NOT plugged in, it again displays the long sequence of “Could not open Serial port” messages; however the programs seems to be operational. At least I could define variables etc. Then when I plug in the Micro:bit, it will keep on displaying the “Could not open Serial port” messages until it detects the port and resumes normal operation.
• HOWEVER: With the new release, if micro:bit is NOT plugged in and while the command.com display is showing the “Could not open Serial port” messages:
  IF I CLICK anywhere on the command.com window, micro:bit program flips to displaying “MicroBlocks (Not Responding) message in the program window header and locks up. Even if I plug the micro:bit at that time, the system will detect the new USB and make the ding noise, but microBlocks will not come out of the locked state.

OK, this was very long winded but I wanted to try the various combos and provide as much info as I could.

Summary:

• BT enabled, prohibits proper detection of COM ports, if BT ports are lower enums than the micro:bit port.
• Any USB disconnect followed by a click on the command.com locks up the program prior to or even after the USB is connected.

Is it NOT possible to open COM ports by finding out the name of the port, rather than grab the first one? micro;bit ports show up as “mbed Serial Port” as opposed to BT ports.

Maybe the command.com window should be “dormant” or not able to accept clicks to prevent the lock ups.

‌

‌

[John Maloney]

Great detective work! It’s good to know that the Bluetooth (BT) COM port is causing the problem. That explains why I was unable to reproduce the behavior.

Is BT built into your computer or are you using some sort of USB Bluetooth dongle? If the latter, which one? If I can get my hands one one, it will be easier to debug this.

It sounds as though, even with the new release and BT enabled, things don’t lock up if you don’t click on the COMMAND window while MicroBlocks is (fruitlessly) searching for a COM port. Is that right?

One thing that would be super helpful to know is when the MicroBlocks behavior changed. Did 0.3.2 also have the problems you’ve described? If so, how far back do you have go in the release history to get to a version that did not have the problems?

The reason I ask is because nothing about the serial port handling code changed between 0.3.2 and 0.3.3. However, we did upgrade to a new version of the compiler and libraries, so if the behavior changed between 0.3.2 and 0.3.3 it is possible that something changed in the libraries. Troubleshooting that would be a very different process than looking for a recently introduced bug in our own code.

MicroBlocks cycles through all the COM ports looking for one that responds to a MicroBlocks “ping” message. So, with no micro:bit plugged in, it will try the BT serial port and get into trouble regardless of the COM port order.

I’ll look into ways to filter the COM ports. We can’t just look for mbed serial ports since MicroBlocks supports many boards in addition to the micro:bit. However, if we could filter out the BT serial ports. The name of the BT port is “Standard Serial Over BT Link”, right?

[Turgut Guneysu]

• Is BT built into your computer or are you using some sort of USB Bluetooth dongle? If the latter, which one?

BT is the one built into my LENOVO Yoga 900.

Here is what I also tested with what I had available:

I have a BlueGiga BLE112 USB adapter. When plugged in, it enumerates to “Bluegiga Bluetooth Low Energy (COM6)”, no matter where I plug it.

With it in place, when I plug in micro:bit, it starts at USB COM4, and microBlocks has no problem working because the number is LOWER than BLE COM6.

However, if I have BLE112 (COM6) in but no micro:bit plugged in, then microBlocks starts, displays the SDL message, followed by the sequence of “Could not open Serial port” messages. But after a while it displays a “Bad message start byte, should be 250 or 251; but is 128” message and then the command.com window closes down, but the microBlocks program window is left running. In this mode microBlocks seems to be running OK. I can plug in the micro:bit, system detects the USB port, microBlocks detects the USB port and turn on the GREEN connection icon. At that point, I have full access to microBlocks and micro:bit; yet no command.com window is open.

This begs the question: why is it open to begin with, if things run OK without it ?

• It sounds as though, even with the new release and BT enabled, things don’t lock up if you don’t click on the COMMAND window while MicroBlocks is (fruitlessly) searching for a COM port. Is that right?

Not Correct ! As long as BT is enabled, microBlocks will not reach a full display of startup screen, and displays the “not responding” message at the window header.

• One thing that would be super helpful to know is when the MicroBlocks behavior changed. Did 0.3.2 also have the problems you’ve described? If so, how far back do you have go in the release history to get to a version that did not have the problems?

I have provided the following table, but as I was installing the various releases, I noticed the following: the start-up command.com message re SDL version has stayed the SAME regardless of the releases. I am NOT 100% sure, but I was under the impression that SDL of earlier releases was different. I do not know how that would affect the problem at hand.

VERSION:	micro:bit NOT PLUGGED in	micro:bit PLUGGED in	BT prevents startup
3.3	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
3.2	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
3.1	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
3.0	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
2.8	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
2.7	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
2.6	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
2.5	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
2.4	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes
2.3	click on COMMAND window: hangs it.	click on COMMAND window: hangs it.	Yes

Let me know if this info helps with anything. It seems inconclusive !

One thing is different or changed at some point:
The behavior of the program with the micro:bit plugged-in and out did NOT generate a long sequence of “Could not open Serial port” messages before. This also coincides with the “GC took 1118 usecs; free 199 words” type of message display, if it helps any. There used to be a single “Write error, serial port n” message and that’s it.

Now, a disconnect results in a long sequence of error displays and maybe creates the opportunity to click on the command.com window during that VULNERABLE state.

IF I can test anything else, please advise.

‌

‌

[John Maloney]

Wow, thank you for the very extensive testing. It must have taken a lot of time to test all those releases.

In all cases, the issue is that clicking on the Command window causes the MicroBlocks IDE to lock up. I will see if I can reproduce the behavior. I agree, it would be good to hide or minimize the Command window by default (although it is sometimes useful for debugging).

From your table, it looks as though this is a long-standing problem, going back to at least as early as 0.2.3. From the title of the bug report I thought the problem got introduced in 0.3.3 but you probably just meant that was the version you were using when you submitted this bug report.

The SDL version is different on Mac (and maybe Linux), so if you’ve every run MicroBlocks on one of those platforms you may have seen a different version. It may also have changed on Windows at some point. Not recently, but you’ve been using MicroBlocks for a really long time.

So, it looks like there are two issues here:

1. Skip Bluetooth COM ports when scanning for MicroBlocks boards.
2. Hide the Command window by default, if possible.

Is that a good summary?

I’ll work on both of these although it may take a while.

Thanks again for your careful testing.

[Turgut Guneysu]

No problems re testing. We want microBlocks to be as robust as possible. I am only on the win10 platform, no Mac & no Linux varieties.

Yes to BT port skip. Hide, but better yet make not "input-able" the command window.

Till next round.

Get Outlook for Androidhttps://aka.ms/ghei36

[John Maloney]

I’ve been able to reproduce the unresponsive MicroBlocks window a few times, although not reliably. I think you need to click on the command window while it is scanning for serial ports and time window for that is smaller on my computer since I don’t have a BT dongle.

Possible workaround: when MicroBlocks stops responding, clicking the Command window and typing “Enter” a few times may get it working again. That seemed to work for me, but after that I wasn’t able to reproduce the “stuck” state to verify it. Does that help for you?

[John Maloney]

I’m trying to figure out how to make MicroBlocks handle the situation where there is BT device and no micro:bit plugged in. Could you do an experiment?

With BT enabled and no micro:bit plugged in, start MicroBlocks. Based on your original post on this issue, the MicroBlocks window should open up blank with “not responding” showing in the title. Now, without clicking on that window or on the Command window, plug in a micro:bit and wait a bit (say 30 seconds). Does MicroBlocks eventually find the micro:bit and become responsive?

I’m adding a workaround for this issue that will allow you to disable the auto-connect (port scanning) feature at startup. You could then use MicroBlocks, even without a micro:bit plugged in. When you want to connect to the micro:bit you’d need to plug it in, then select the correct COM port from the menu. (You might need to check the windows device manager to figure what the correct COM port is.) This is obviously just only for emergency situations until I find a more robust solution.

Finally, just to clarify: reverting to 0.3.2 did not fix this problem, did it? I think this issue is a long-standing problem (ever since auto-connect was introduced, I’d guess).

Thanks!

[Turgut Guneysu]

I tested it the way you described it. Waited well over a minute after plugging in the micro:bit.

It does not get responsive when the micro:bit is plugged in.

I don’t know if it will help, but I checked the the TASKMANAGER status of both microBlocks IDE and the Command window.

Both were showing no activity:

‌

As I was researching how to inspect the HUNG program status, I came across this utility from NirSoft:
https://www.nirsoft.net/utils/what_is_hang.html

It will display process info of the hung program. I am hoping it will provide you some info.
You will have to download the 32-bit version, extract it to a directory. Then run the microBlocks after enabling Bluetooth Service and after the microBlocks hangs, run the WhatIsHang32 program. It will list a set of programs, pick the ublocks-win.exe program and press F9. After that it is all YOURs !

If you cannot run this utility for some reason, I can send you the two DMP files I created. Let me know.

I did a capture of a good and bad runs of the program using the SimpleDebugger utility of the same company. Maybe it will be helpful. Files are attached.

‌

Let me know if I can test anything else.

‌

‌

[John Maloney]

Thank you for all this info. Very helpful!

You wrote:

It will list a set of programs, pick the ublocks-win.exe program and press F9. After that it is all YOURs !

Does that mean that after hitting F9 MicroBlocks recovers from being hung and starts to work again? Is that with a micro:bit plugged in?

Based on that observation and the two debugger runs, I’m coming up with this hypothesis: attempting to open the COM port associated with the BLE dongle is raising an exception that is causing the process to hang. The “whatIsHang” program allows you to proceed after the exception, and MicroBlocks continues its port scan and eventually finds the micro:bit.

A test of this hypothesis would be to start MicroBlocks without a micro:bit plugged in. It should hang when it hits the BLE COM port. Hitting F9 in “whatIsHang” would allow it to proceed, but it would quickly cycle around and try the BLE COM port again, thus hanging. If you then plugged in a micro:bit and hit F9 again it would proceed and this time it would find the micro:bit, so it it wouldn’t hang. Looking at the SimpleDebugger info for that run, you’d see a couple of “Exception Code: 0xc0000005” errors associated with each time it got hung.

If this hypothesis is correct, then the only way for MicroBlocks to avoid getting hung is to not to even attempt to open the BLE COM port. It might do this by using the “friendly name” of the COM port to filter out the BLE port. Unfortunately, it’s a bit tricky to get the friendly name, but its possible. I’m looking into a couple of ways to do it.

Meanwhile, the next release will have a work-around. Hitting the space key while MicroBlocks is starting (within a second) will put it into “disconnected” mode, disabling port scanning. Thas will keep MicroBlocks from hanging whether or not you have a micro:bit plugged in. When you want to connect, you’ll need to manually connect to the micro:bit by clicking on the USB icon and selecting the appropriate COM port from the “Connect” menu. You’ll also need to select “disconnect” from the “Connect” menu before disconnecting the micro:bit. This isn’t a good long term solution but it will give me time to work out how to get the friendly names of the COM ports.

Thanks again for your help. This issue came one once before (also associated with a BLE dongle on a Windows laptop) but I didn’t get enough information to fully understand the problem. (In the case, the person just uninstalled the dongle software since they weren’t using it anyhow.)

[Turgut Guneysu]

I am sending you the HangReport from my system, in case you are not able to create it

[Turgut Guneysu]

Does that mean that after hitting F9 MicroBlocks recovers from being hung and starts to work again? Is that with a micro:bit plugged in?

No micro:bit is not plugged in and F9 does not unhang it.

Here are the sequence of events:

• micro:bit is NOT plugged in. I enable Bluetooth device in Win10. It enumerates a COM3 port.
• I run microBlocks and it hangs.
• I execute the WhatIsHang utility and select ublocks-win.exe from the displayed list.
• Pressing F9 displays the HANG INFO about the program.
• It does NOT unhang the program.

A copy of the report from my system is attached in the message before.

You mentioned needing to find out the FRIENDLY NAMES of the USB ports. The USBDeview utility of the Nirsoft company does that: https://www.nirsoft.net/utils/usb_devices_view.html Hope it will help.

CLARIFICATION:

You refer to a Bluetooth DONGLE. I do NOT have a Bluetooth DONGLE. My laptop has a buil-in Bluetooth device. When enabled it will enumerate a COM3 port. SInce this is lower than the COMn of the micro:bit, it leads to the HANG situation. Probably makes no difference, but wanted to clarify it.

I am happy about the SPACEBAR temporary solution. It will be useful until the final solution. If you could also implement the USB port Info I had described in one of the other ISSUES (#74) I submitted, it will be a nice package.

Thanks.

[John Maloney]

Is the the space-bar workaround working for you in 0.3.4?

[Turgut Guneysu]

Yes John. That is of great use. I already used it several times after forgetting that BT was on. Still need the connected USB port info to differentiate the multiple mbits connected. But I know it is not critical.

Get Outlook for Androidhttps://aka.ms/ghei36

[Bernat Romagosa]

Is this still happening?

[John Maloney]

All these issues have been addressed and resolved.