I2C bus busy when using telnet

update: fails on D17/D16, works on scl: D18, sda: D19.

Is the telnet function somehow using rx2/tx2, or does the process of switching the console/enabling it demux the i2c into the default uart2 rx/tx pins?

Anyway, it would seem the easy solution is to use other pins. I'm curious to try destroying the I2C1 object and reinitialize it after telnet opens to see if that forces the pins back into working order.

... ...

So, my configuration:
bme280, default address, scl/sda pulled up w/ 10k, scl: D17, sda: D16
esp32 wemos lolin lite using 1.96_35 (also tried 1.95_165)

the general program structure is the ESP32 is a WebSocket client. When it receives a message, it executes a function based on the msg data, then returns any info needed (in this case, temp, humidity & air pressure) to the WebSocket server.

This works wonderfully when connected to USB (via the Web IDE), or just to power (without Web IDE access).

The problem is when you attempt to connect to the ESP32 via telnet, both in Web IDE and a regular Telnet client, the I2C bus repeatedly reports "bus is busy" messages.

ERROR: jshI2CWrite:, Operation timeout because the bus is busy.
ERROR: jshI2CRead:, Operation timeout because the bus is busy.

I've tried connecting via the ttyUSB0, while also connecting via telnet, however, it seems the console gets redirected on Telnet connections.

Of course, the easy work-around is not to connect via telnet, however, that is a super useful way to get code updates without having to plug in.

Also, I've reproduced this error on a "DOIT espressif DEVKIT1".

other steps I've taken to isolate the issue:

to remove the websocket code, I used the following:

I2C1.setup( {
	scl: D17,
	sda: D16,
	bitrate: 100000
} );
var bme = require( "BME280" )
	.connect( I2C1 );

setInterval( function() {
  console.log(bme.getData());
}, 5000);

then telnet in again and I get the same error.

I've tried initializing the I2C1 object with various bitrates. Same error.

As far as I can tell, only reloading the code via TTY will reset the issue. That is to say, a simple power off/on results in continued bus timeouts and garbage data. I've started digging around in the esp-idf I2C code, but i'm little bit out of my depth there. However, I tried adjusting the timeout defined in src/jsi2c.c on line 45 from 100k to 1k to 500 with no noticeable difference.

It also appears to be blocking the JS interpreter as nothing else executes while waiting for the timeout to finally be returned.

Some other random observations include the internal_pu is enabled (which I believe is a 50k pull-up on pins D16/D17. When I'm adding my own pull-ups, they are in parallel (i'm assuming). I've tried 1k, 4.7k, 10k & none, with all the variations resulting in the same timeout issue. It doesn't seem to happen with WebSocket traffic, only with Telnet access.

Anyway - perhaps someone has run into this already?

I found a kind of work around & created an issue in GitHub. -- https://github.com/espruino/Espruino/issues/1362