Problem with setWatch on MDBT42Q

Sat 2020.01.04

Thank you @Oscar I use that same code/test ritual also. One question I forgot, which PC OS are you running with? Most here seem to use Linux or a variant, I am running Windows10.

I'm posting the following observation more to inform @Gordon and the Espruino project masters, and to determine if there is common denominator, e.g. device type, developer coding/testing practice, WebIDE, PC OS issue, other.

recap - may jump ahead to bold heading and come back if necessary

I had what I filed under bizzare issues when using a Pico on a previous HP Notebook laptop running Windows10 which I had successful coding for web development C# HTML and Javascript with all major browsers, for several years.

The first started around July of 2017

http://forum.espruino.com/conversations/­308441/

which I thought was the WebIDE as updating did occur for a while, but this may have been BLE as it was in the early stages for Windows10.

Then in Sept of 2018

http://forum.espruino.com/conversations/­325378

which we did resolve as being an issue with how the WebIDE used relative paths within Windows10 when that OS uses the \documents folder for saved app locations along with
connection issues in Aug of 2018

http://forum.espruino.com/comments/14385­130/

Then in July of 2019 a Windows10 update nightmare

http://forum.espruino.com/conversations/­336539/

and recently, while undocumented on this site, another, the 2nd 'Blue' screen of death (not 'Black' screen) on my new Asus screamer RAM drive laptop while leaving my laptop on overnight, updates as 'download only install by user' enabled, auto rebooted leaving just the 'Blue' screen visible.

So in my case, as we now had a second PC involved, different hardware, different BIOS, version difference in OS, but version change in WebIDE and many updates/changes with Espruino, I thought that it was more to do with Windows10. (up until a month ago)

Recently in Oct 2019 the perceived bricked MDBT42Q

http://forum.espruino.com/conversations/­340193/

After finally getting Espruino back on to that device, AND AFTER the latest Windows10 upgrade started noticing some really bizarre behavior. The only recovery means after lockup I've been able to preform is to:

• Disconnect the WebIDE
• Close the WebIDE
• Power down the MDBT42Q breakout board
• Power on the MDBT42Q
• Open the WebIDE
• Open Windows10 settings
• Open Bluetooth Devices
• Start 'Add Device'
•    *(without the above three lines, the WebIDE will report 'failed' to connect always)*
• Connect to WebIDE Orange button

 

Should I uncover more related items, I'll open a new thread with this and future discoveries

 

EDIT:
Just opened a new instance of the WebIDE after a recent power on and reboot of Windows10. It is repeatable that needing to 'Add Device' is required before the WebIDE will now connect. See section and last four steps in above bulleted list. (also after last Windows10 update) It isn't necessary to remove and re-pair the device, although initially I thought that was improving things.

This is on a new mfg six month old Asus with internal BLE running Windows10. It is an absolute royal pain when the following does occur, as the sequence to get re-started is time consuming.

Now the interesting part and how it relates to @Oscar and this thread


A common device, the MDBT42Q and common Javascript functions.

My coding/testing method is, and most likely is what most of us do in fact do, that we write code in the WebIDE Right-hand editor side and save the file for easier/quicker future upload. We then test and add future snippets by either typing directly or block copying into the Left-hand console side.

I started to notice that when using setWatch(); setInterval(); and specifically block copying into the Left-hand console side, would after at least three tries and after typically at least five minutes of WebIDE code/test uptime, just lock up the WebIDE, with no ability to move the cursor carret in/from the WebIDE Left-hand console side. After several weeks of attempting to find a work around, determined the above list to be the only reliable means to get going again. I notided this last week, that sometimes the red LED on the MDBT42Q breakout board would sometimes flash at the exact moment the lockup occurred.

I used to use save(); but gave up during development, as the reverse process to get rid of code was needed in addition to the above steps, waisting even more time.

But WAIT there's more . . .

My recent Aug 2019 struggle with getting @Gordon 's functioning code to work on my platform:

http://forum.espruino.com/conversations/­336859/
including response #8 and #15
http://forum.espruino.com/comments/14847­972/

. . . and, . . . In this thread, @Oscar made several comments regarding unusual anomalies, that when re-read, do in fact make one wonder if Mother Nature or Physics is not as we really understand it. Experience and common sence however, lead us to understand that there is a common denominator, just have to find it.

setWatch(); setInterval();

I have discovered that under some circumstances, it is possible to place the device in a state that is un-recoverable and, as @Oscar also found out, leads to unbelieveable and bewildering troubleshooting also. It appears the only recovery is to get rid of all uploaded code, and start fresh as in his #11 post.

One of which is not fully remembering that a timer is running when attempting to re-send the exact code a second time. That could be considered a developer fubar, but what about the condition where the WebIDE locks up? I got burned on this, when I disconnected the WebIDE and reconnected, making the false assumption the board would restart. It wasn't until many hours later, and after remembering the snippet below, that I would discover many timers running, and even after using clearInterval() would realize the old timers where still there. It is even nastier when using setWatch()!!

The other is as @Oscar found out that when both are saved into flash, that even attempting to upload them, won't change the underlying behavior. But, as we have learned in this thread here, one has to discover this fact. To Oscar it appeared as if a digitaRead() wasn't working as defined, when in fact it most likely was one of the other items, causing the mis-behavior.

Found this in the forum for others and specifically @Oscar to see whether timers are running:

  console.log(global["\xFF"].timers); //nice, less info
  trace(global["\xFF"].timers); //full info

Is there a similar means to see whether watch's are running?

Observations:

• Over the last year have noticed forum postings on users having connect/dis-connect issues
  
• Common denominators MDBT42Q, setWatch(); setInterval();
  
• Left-hand console copy of identical code not always reliable (setWatch(); setInterval();)
  
• Now documented, TWO independent developers using similar adopted code/test technique
  
  

EDIT:
With @Oscar 's #16 post are temporarily ruling out windows10 for setWatch
The 'failed connect' seems to be an independent issue - might be related to last update - build 17763.914 Feature update to Windows 10, version 1903 - Nov 2019

While I'll file this as an anomaly that occurs when copying identical code into the Left-hand console side, when that code currently resides in RAM (and possibly ROM; save();) it is an issue that others may trip into, I still wonder if there is an underlying process that isn't working quite right or up to par.