-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP32 hard crash on i2c display #4962
Comments
I get also a hard crash when using the the SPI display on the Kaluga V1.2 . It worked a month ago. Happens at the same line of code (except SPI bus) |
SPI seems to work now, as of build today (5756ddd). I see some SPI fixes were commited |
I2C works OK on an ESP32s2 SAOLA-WROVER with the current tip of main.
|
And it also works now , for me, on a FeatherS2 (using an OLED SSD1306 featherwing)
|
Trying to reproduce the failing test setup - I have a STEMMA OLED SSD1306 132x64.
|
It works fine when running in REPL the first time, but crashes on
|
Ah -- that reminds me of a very old issue I ran across on the feathers2 -- I had that problem if I used the .uf2 bootloader, but not if I flash with the .bin file .... I have not been using the UF2 bootloader on the featherS2 or the Saola |
Ah -- never mind -- I just crashed mine trying to run the code after a soft reboot.... |
but it crashes before the last line -- mine crashes on the import adafruit_displayio_ssd1306 line |
@jfurcean if found that it works if I do a
after the soft reboot then I can run the code repeatedly after soft reboot if I release the display each time. |
I wonder if this is a displayio issue -- or even an expected behavior if the display is not released. |
Well -- that does not make senses since the code does the release, but for some reason, it has to be done before importing the ssd1306 library...
|
It also works fine with QT PY Haxpress and the QT PY RP2040 without changing the order.
|
it does seem like an issue with the esp32s2 ...
|
oops -- accidental close |
The This sounds like some kind of a race condition — maybe there is a delay required between releasing the displays and creating a new displayio display. Maybe because it's still updating one frame in the background? |
A garbage collection is done after each import, so I wonder if it's a storage management problem. |
This keeps the mutex info in the same spot in memory. "Statically allocating it" with CircuitPython meant that the buffer moved when the I2C object is moved to keep it alive for a display. Fixes #4962
CircuitPython version
Code/REPL
Behavior
This code crashes on the final line using a Feather S2 and the STEMMA QT 0.91" OLED Display 128x32.
Description
Additional information
No response
The text was updated successfully, but these errors were encountered: