I2C bus busy when using telnet #7079
Unanswered
espruino-discuss3
asked this question in
ESP32
Replies: 1 comment
-
Posted at 2018-04-01 by jgtaylor I found a kind of work around & created an issue in GitHub. -- espruino/Espruino#1362 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Posted at 2018-03-30 by jgtaylor
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.
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:
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?
Beta Was this translation helpful? Give feedback.
All reactions