Unable to upload code to the Pixl.js running 2.18, disconnects while sending

I've updated my Pixl.js to to 2v18 and I'm unable to upload code (either to ram or flash) because it seems to disconnect in the middle of sending.

Copy pasting code also disconnects the pixl. However, typing in code seems to work (testing with the blinky code).

My MDBT42Q breakout works correctly but that was running the 2.06 version. I then flashed 2.06 onto the pixl and uploading code works again.

I don't remember the version my pixl was running before I updated. I've tried 2.17 and 2.16 but those are broken too, I'll try to find out the latest version the pixl still works corectly with in the next few days because I'll need to finish off a project and 2.06 is enough to get things working :)

I just updated my MDBT42Q from 2.06 to 2.18 and I'm facing the same issues.

Argh, sorry to hear this. so just to narrow it down:

• If you connect and type in the REPL, it's all fine?
  
• What if you copy and paste a chunk of text into the REPL - say 50+ characters?
  
  

You could try enabling Throttle Send in the Web IDE communication settings?

What type of computer/OS are you using? Does it work if you use a different computer or a phone via 'remote connection' (click the text at the bottom left of the Web IDE connect window on your PC) ?

Two people posted up a week or so ago that they'd had something very similar with Windows 11 - one of them mentioned that they had a Logitech Bluetooth keyboard and when they turned that off it all worked fine.

If it's the same issue it appears to be to do with the Bluetooth MTU, and the last firmware with the lower MTU was (I think) 2v08. It's a hard one - while I could produce builds with a lower MTU again that slows things down, and this would appear to be a due to broken driver on Windows 11 :(

If you connect and type in the REPL, it's all fine?

yeah, if I type in the blinky example line by line it does work

What if you copy and paste a chunk of text into the REPL - say 50+ characters?

this one I'll need to confirm again, but I tried pasting the sample code on the 433 remote socket example and it disconnected. I'll be able to confirm again in a few hours (I'm out right now)

What type of computer/OS are you using?

I am indeed using Windows 11 (the BT stack on my Ubuntu 22.04 leaves much to be desired, but I can try with it again once it does work). I can also boot up a live Ubuntu image on this laptop to try things out.

I don't use any other BT device on this laptop aside from earphones, but I'll try again later with all BT disconnected aside from the pixl.

Is there a way to change the MTU for bluetooth on Windows 11? I'll also try flashing 2.08 then 2.09 and see if that is indeed the bisection point.

for me reloading the IDE page often helps (shift + reload button), or maybe exit/relaunch Chrome,
see also https://forum.espruino.com/conversations­/387281/

Can you try to paste text of 22 characters and then only 21 if it is MTU issue?

Sorry I wasn't able to reply immediately; had to reflash the pixl to 2.18 first.

I copy and paste this:

var a = "123456789";

and that works.

However,

var a = "1234567890";

will disconnect the pixl.

(i'm probably copying a LF at the end that's why the total count was only 20/21)

Thanks for testing that! Ok, so then it's exactly the issue described in https://forum.espruino.com/conversations­/387281/

So enabling Throttle Send in the Web IDE communication settings should fix it I think.

But at this point I'd be pretty certain this is a bug in whatever Windows 11 Bluetooth Driver you're using I'm afraid. It's probably not a coincidence that this change to Espruino went in over 3 years ago and nobody had any problems until about a month or two back.

I wonder if you all have the same Bluetooth radio in your PCs? If you have a look in Device Manager, what does it say?

Maybe trying to get the absolute latest driver would fix it?

So it looks MTU related. Which is strange because the IDE sends larger chunks back only if it first receives larger chunks too. And AFAIK in BLE there is only one MTU negotiated (?) for a connection between two devices, there is not a different MTU per direction. So it may be some Chrome bug that it somehow forgets that higher MTU is negotiated.

Does reloading IDE help or maybe removing the device from Chrome bluetooth devices as mentioned in that other topic linked?

Do you have more that one BLE device connected? - the other thread was mentioning keyboard.

Also the question (to @Gordon ?) is, can this error/exception be handled in the IDE javascript code and retried instead of closing the connection or does Chrome itself closes the connection.

I only have bluetooth earphones paired with this laptop (which I wasn't using when doing the tests).

I was using Edge btw (which is based on Chrome afaik)

I haven't tried removing the device from the bluetooth devices but I'll try it again next time I'm able.

I'll also try a different bluetooth adapter (I have a Feasycom one similar to that sold in the Espruino shop)

1 Attachment

I just tried with that bluetooth adapter (the one built-in to my thinkpad was a mediatek, this adapter shows up as a realtek) and everything works (send to Espruino button, as well as copy pasting).

This works for me right now, thanks for the suggestion :)

Not sure how else to update drivers for the mediatek one as I never had to install one in the first place (everything is managed though windows update)

Thanks! Ok, so that's one for Mediatek. @parasquid it'd be amazingly helpful if you could try the other adaptor - that would rule out a great deal of things!

@fanoush as far as I can tell from the initial post on https://forum.espruino.com/conversations­/387281/ we get a NotSupportedError: GATT operation failed for unknown reason. from https://github.com/espruino/EspruinoTool­s/blob/master/core/serial_web_bluetooth.­js#L226

And that function does trigger a disconnect - so it is possible that we could trap the error there, and then split the write up into 20 byte chunks.

It could maybe even set setMaxPacketLength(NORDIC_DEFAULT_TX_LEN­GTH) and change where setMaxPacketLength is called above to ensure it never tries to send >20 byte packets.

... but I'm hesitant to make changes here as I can't reproduce it. If you were willing to give it a try a PR would be awesome though.

@parasquid that's awesome - thanks for checking! I'm not entirely sure about updating drivers either and it feels like Mediatek don't directly release them.

I did spot https://www.catalog.update.microsoft.com­/Search.aspx?q=Mediatek+Bluetooth though and I guess it's possible you could find the version before the one you have currently and manually download and install that?

I tried installing the updated drivers and older drivres, but it doesn't seem to update the actual installed driver in the system (Windows will either insist that the best drivers have already been installed, or if I do manual installation by browsing and selecting the device I want to install drivers for, it will install them but the driver version remains the same even after a reboot).

If you were willing to give it a try a PR would be awesome though.

If you're also able to deploy this to a test URL (so something like espruino.com/ide-mtu-test for example) I can try it out and see if it works without any configuration on my part.

Also, just to round out all of the suggestions, setting throttle send to "Always" also allows me to send to Espruino as well as copy/psate code without getting disconnected (although I can subtly notice that pasting the code isn't as smooth as when using the adapter and having throttle send to auto; it's like using ssh over a slow network connection)

but I'm hesitant to make changes here as I can't reproduce it. If you were willing to give it a try a PR would be awesome though.

Sadly I cannot reproduce it either. It does happen to me sometimes but I did not trace it to something specific, mostly it just works. And when it does not work reloading IDE works or it otherwise goes away soon (for no apparent reason). I only know simple disconnect and reconnect in IDE does not help in this case.

As for the error handling- what could work in this case:

• fall back to 20 and retry if it was not already 20
  
• if it already is 20 then disconnect.
  

I haven't tried removing the device from the bluetooth devices but I'll try it again next time I'm able.

Just to be sure, I mean this Chrome page chrome://bluetooth-internals/#devices

this Chrome page chrome://bluetooth-internals/#devices

Just tried this, there's nothing in there (I see the Devices and the table headers but nothing listed).

1 Attachment

Quick update: I was able to connect with the Mediatek BT on the Seeed Xiao BLE (and possible the Bangle.js 2 which I'll have to hunt for) without having to throttle send.

I thought something got fixed since there was a windows update and I had to reboot, but unfortunately the Pixl.js still had the same issues (disconnecting when sending code).

So it seems my BT adapter is fine with nrf52840 but not with nrf52832? I'll try again when I find my Bangle.js 2 charger :P

What's the Xiao BLE running? Because most devices don't have the increased MTU - it was just done with Espruino to get the data throughput a bit higher and to make it compatible with connecting to the few that do.

What's the Xiao BLE running?

It's running a custom compilied Espruino here: https://forum.espruino.com/comments/1703­4513/

it's on the nrf52840

I've found my charger and charging up the banglejs 2 and will confirm with you if my Mediatek performs properly without having to throttle.

Yep, confirmed with the banglejs2 (running 2v18) that copy and pasting long seuqences of characters don't disconnect me.

This is what I was copying and pasting:

const state = {
  led: true,
  curTemp: 0,
  prevTemp: 0,
  setTemp: 0,
  offset: 53,
  isRelayOn: false,
  isRunning: false,
  dirty: false,
};

doing the same for the mdbt42q (running 2v18) disconnects (and doesn't even show anything on the screen.

1 Attachment

Ahh, neat - I bet if you added these lines:

     'DEFINES += -DNRF_SDH_BLE_GATT_MAX_MTU_SIZE=131', # 23+x*27 rule as per https://devzone.nordicsemi.com/f/nordic-­q-a/44825/ios-mtu-size-why-only-185-byte­s
     'LDFLAGS += -Xlinker --defsym=LD_APP_RAM_BASE=0x2ec0', # set RAM base to match MTU

You'll find it breaks - similarly if you removed those from the Pixl's python file and built yourself I bet it'd work great.

I missed this last post - so you mean an up to date Bangle.js 2 using firmware we built does not disconnect itself when you send >20 chars? That is interesting...

Aha sounds great! I won't have to lug around a BT dongle if this works :)

So I guess this was indeed an MTU related issue, that only affects certain builds with those defines and only on certain BT adapters.