SetConsole, ...

Now that Bluetooth.print works fine, next step is to test Bluetooth as console.
First step is to write a simple function, which

1. set a timeout
   
2. in this, timeout set bluetooth to console
   2.1. set one more timeout
   
3. in this timeout set Console back to Serial1
   Some prints are added to each step.
   
   

Expectation for this function is,

• after 1 sec console is switched to Bluetooth, which happens
  
• 5secs later console is switched back to Serial1, which never happens
  
  

Hopefully the following description is not too confusing

function testConsole(){
  setTimeout(function(){
    Bluetooth.setConsole(true);
    setTimeout(function()  {
      //Bluetooth.print("BT \n");     Serial1.print("Ser BT \n");
      Serial1.setConsole(true);
      //Bluetooth.print("SER set\n"); Serial1.print("Ser SER set\n");
    },5000);
    //Bluetooth.print("BT set\n");    Serial1.print("Ser BT set\n");
  },1000);
}

Testing itself is

• upload the function
  
• start uart service in WebIDE
  
• connect from my android to uart service with nRF UART v2.0
  
• call the function TestConsole in WebIDE
  
  

On WebIDE I see

testConsole() // start of function(see function above)**
=undefined
-> Bluetooth // Message from firmware
Ser BT set // Bluetooth is set to console
Ser BT // before setting Serial to be console

                               // message missing from firmware, that Serial1 is switched back from BT
                              // message missing from 2nd setTimeout, that serial is set to console

In nRF Uart everything looks like expected

RX: <- Serial1 //message from firmware, console switched from Serial1 to BT
BT set // Bluetooth is set to Console
BT // before switching back to Serial

[J->Serial1 // message from firmware, console switched to Serial
RX: Ser set // message from 2nd setTimeout, console is switched back to Serial1

What happens if you just try LoopbackA.setConsole();Serial1.setConsole() - so no Bluetooth involved at all. Does that work?

And if you just do:

Bluetooth.print("foobar");
Bluetooth.on('data',x=>print(JSON.stringify(x)));

Do normal bluetooth comms all seem to work ok?

It might just be that DeviceInitialised isn't set for Serial1, so calling Serial1.setConsole at all causes it to get reinitialised, which breaks it?

Oh, LoopbackA.setConsole(), and I get an illegal instruction panic
If I call Serial1.setConsole() without LoobackA.setConsole before, everything looks fine.
Now have to do some work to check stack and see how panic happens.

Problem starts in jshUSARTSetup, have to dig deeper.

Oh, this problem is fixed, default in switch for serial ports was wrong.
But now the problem is the same as before with Bluetooth.
Console does not come back.

One more chance for me to dig deeper, .....

Problem was missing SetDeviceInitialised for Serial1.
Now LoopbackA.setConsole() and Serial1.setConsole() works fine.

BTW, looks to me, like LOOPbackA and LoopbackB are not initialised, at least flag is not set.

One more success, Bluetooth.setConsole works fine, and next Serial1.setConsole from my Android with nRf UART V2.0 returns control to webIDE.
Life can be so beautiful.

Now I've to figure out, why Windows10 does not like my ESP32, .......

I think with windows 10 you have to pair the device - I think that's what you to do with a puck - I've not tried for a while as the web Bluetooth support is lousy under windows and I think the latest chrome has only partial notification support.

@Wilberforce, thats correct, first of all I've to pair in Admin screen. Same as with Puck.
With actual version this step works fine, I see connected.
If devicename is like PUCK* or Espruino now, the board is shown in Select list of WebIDE
After click on connect, connection starts. on ESP32 I see the connected event
Next, after a second or two, an MTU event appears which gives size of MTU (AFAIK) only
And then, 3 more seconds later we get a disconnect event.

Does windows expect something, that ESP32 does not deliver or ????

BTW, looks to me, like LOOPbackA and LoopbackB are not initialised, at least flag is not set.

Yes - same with Bluetooth. I'd just ignore any request to USARTSetup a device that you don't know about.

Does windows expect something, that ESP32 does not deliver or ????

Seems strange... You could give this a try and see if it gives you any useful errors? https://www.microsoft.com/en-us/store/p/bluetooth-le-explorer/9n0ztkf1qd98