ESP32 WROVER-I --- Uasyncio results in reboot (?PSRAM bug)

All ESP32 boards running MicroPython.
Target audience: MicroPython users with an ESP32 board.
Post Reply
doceave
Posts: 26
Joined: Fri Feb 14, 2020 4:02 pm

ESP32 WROVER-I --- Uasyncio results in reboot (?PSRAM bug)

Post by doceave » Sat May 23, 2020 6:30 am

Recently we completed a prototype device which employs an ESP32-WROOM module --- this worked admirably albeit that the device is short on RAM and can thus only buffer +- 500 seconds worth of sensor data with which to make decisions. Five times this number is desirable.

The WROVER module with SPI RAM on board was thus integrated into the final design.

Despite the exact same connections to peripherals, and the exact same code, the WROVER module simply resets when code is run. In a troubleshooting effort we tested sections of the code and found that simple synchronous code runs without problem. The memory intensive component of the program is resulting in what looks like a hard reset immediately after being imported. Additionally, even simple uasyncio examples are resulting in the same.

Attempts have been made to:
> Use a different WROVER module (same batch)
> Use SPIRAM IDF V3 latest, and SPIRAM IDF V3 stable
> Save data to flash or reference later (and thus stick to WROOM module) --- read/write times are too long for implementation

Sadly the have no logs to post at the moment (these will follow in a subsequent post). But what I hope for is a more general answer ito:
> Is anyone else experiencing this?
> Is this one of the ESP32 silicone bugs declaring itself?
> Is this solved with a ESP32 rev 3
> Would IDF V4 help?

REPL output to follow (apologies)

User avatar
tve
Posts: 214
Joined: Wed Jan 01, 2020 10:12 pm
Location: Santa Barbara, CA
Contact:

Re: ESP32 WROVER-I --- Uasyncio results in reboot (?PSRAM bug)

Post by tve » Sat May 23, 2020 3:35 pm

Have you double-checked the strapping pins?
Please post logs starting from the reset.

Post Reply