01space_lcd042_esp32c3 crashing to safe mode on hard reset.

[SeanTheITGuy]

CircuitPython version

Adafruit CircuitPython 8.2.10; 01space_lcd042_esp32c3
Adafruit CircuitPython 9.0.0-rc.0-13-g39b16feaa0-dirty; 01space_lcd042_esp32c3

Code/REPL

print("Hello World!")

Behavior

Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40048b82
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0xd0
load:0x403cc710,len:0x7c8
load:0x403ce710,len:0x2518
entry 0x403cc710

Auto-reload is off.
Running in safe mode! Not running saved code.

You are in safe mode because:
CircuitPython core code crashed hard. Whoops!
Heap allocation when VM not running.
Please file an issue with your program at github.com/adafruit/circuitpython/issues.
Press reset to exit safe mode.

Description

After a fresh flash of 8.2.10 up to and including 9.0.0-rc0.13, CircuitPython will boot perfectly fine, displaying the logo and wifi off info on the LCD. After a power cycle, it also works fine. However, if you push the reset button, it boots with the above error:
No amount of ctrl-D soft-boots bring it back to a functional state. When the board is in this safe-mode crashed state, the LCD is still being updated. If I have pushed a settings.toml to the board with my wifi credentials, I can see the LCD update from No IP to the obtained IP.

Additional information

No response

[tannewt]

Do you have an espressif devkit you can test on? I don't have this board to test with.

Are there any log statements before the build line? The actual error happened before the reset.

[SeanTheITGuy]

I can test, yes. There are no log statements before the build line, neither via usb uart or hooking an external usb serial device to pins 20/21.

edit i did get that one more ESP-ROM line out of it when i used the external usb serial

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
Saved PC:0x40048b82
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0xd0
load:0x403cc710,len:0x7c8
load:0x403ce710,len:0x2518
entry 0x403cc710

is the entirety of it.

[jepler]

you mentioned on discord that this same board works when flashed with the qtpy firmware.

I'd check whether removing display initialization fixes it; if so, it greatly narrows the range of stuff to look at.

[jepler]

(that seems to be the main difference, aside from the content of the board module)

[SeanTheITGuy]

In this variant, it looks like the entire board_init() function is dedicated to the construction and initialisation of the display.
Commenting out everything inside board_init() does seem to allow it to be reset without crashing, indicating that it is a problem talking to the display.

[SeanTheITGuy]

This appears to be a hardware issue. As silly as it sounds, if I hold the board (thus giving a high resistance continuity to several pins) it boots stable every time. If I lay the board on a non-conductive surface and push the reset button with a probe, it crashes on reset every time. This is very repeatable.

edit: except, as someone mentioned, it DOES work with arduino code.. I'm baffled.. I've ordered another one to rule out hardware fault.

[dhalbert]

The schematic for the original board is here: https://github.com/01Space/ESP32-C3-0.42LCD/blob/main/Schematic/ESP32-C3-0.42OED%20Schematic.pdf. I don't see any pull-up resistors for SDA and SCL on the board. Ideally there should be 10k or so pullups somewhere. Maybe they are on the display itself, maybe not. CircuitPython checks for pullups, and might initially fail creating the I2C bus because of that (though I'm not sure why the display would then sort of work).

Try setting CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP = 1 in mpconfigboard.mk. This may or may not help,

[SeanTheITGuy]

It did not help. I've ordered a second board for testing to ensure it isn't a fluke occurrence. One thing I note is that, if one solders pin headers to this and puts it in a bread board, one loses access to the reset/boot buttons as they are on the bottom. I wonder if it does affect all of these units, but given it's relative lack of use and difficulty of actually using the reset buttons, it has gone unnoticed, or at least unreported.

[SeanTheITGuy]

Update: Under further testing, putting 10K pull up resistors on I2C pins 5 and 6 resolves the issue. I would consider this a closed matter filed under poor hardware design, however, as stated before, sketches compiled under the Arduino framework do work. Could there be a difference in the way the CircuitPython vs Arduino bootup sequences do things that could explain it? I've tried enabling the internal pullups in board_init before initalizing the lcd, as well as in espressif_board_reset_pin_number. Additionally I added #define CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP (1) to mpconfigboard.h.

[jepler]

aren't these pull up resistors on the relevant lines? (it is weird that there are 3 R4s on the schematic though, there's another on on IO8)

[dhalbert]

I missed those resistors the first time I looked, sorry. However, this board is a clone, not the original board, and maybe they omitted the pullup resistors.

Another possibility is that the resistors are there, but you made the pullups stronger, which may help.

Since CIRCUITPY_I2C_ALLOW_INTERNAL_PULL_UP = 1 did not help originally, it might be because we are checking for pullups when creating the I2C object. If this is turned off, via CIRCUITPY_REQUIRE_I2C_PULLUPS = 0 in mpconfigboard.mk, that might help as well.

You could measure the resistance from 3.3V to the SCL and SDA pins to see what is going on and whether the pullups are present. You will also be measuring some internal resistances on the chip, but you may get a general idea.