MicroPython on ESP32 with SPIRAM support

[loboris]

Wondering why is the reset reason RTC WDT reset when a hard reset is performed ??

This is caused by the ESP32 rev. 0 chip bug:

... behaviours are described in the errata document:
http://espressif.com/sites/default/file ... p32_en.pdf

When the ESP32 (rev. 0) is powered on, a spurious RTCWDT_RTC_RESET occurs. There is no workaround for this issue. It will always happen for rev 0 silicon, and is fixed in rev. 1. ESP-IDF contains a workaround to prevent this issue from happening after deep sleep.

When the ESP32 (both rev. 0 and rev. 1) is powered on, or restarts after deep sleep, it may access the flash chip before the flash chip is fully powered on. Whether this issue occurs or not depends on the flash chip startup time. At power up with rev0 silicon, this issue is masked by the previously mentioned one. But it can be observed using rev0 silicon after deep sleep reset (your case) and both at power on and deep sleep reset when using rev1 silicon.
ESP-IDF contains a workaround for the deep sleep reset case: you should set "Extra delay in deep sleep wake stub (in us)" option under "ESP32 specific" menu in menuconfig to some value like 500 (microseconds). This option introduces certain delay after deep sleep reset, which allows the flash chip to start up before the ROM bootloader will try to read the application.

[EasyRider]

Noob question.

Trying to build firmware for esp-wrover-kit to use SPI-RAM.

I think I have followed building instructions but the board fails to initialize.
with most default config settings, except

To build with psRAM support:

In menuconfig select → Component config → ESP32-specific → Support for external, SPI-connected RAM

In menuconfig select → Component config → ESP32-specific → SPI RAM config → Make RAM allocatable using heap_caps_malloc

Error during boot.

E (382) spiram: SPI RAM enabled but initialization failed. Bailing out.
E (388) cpu_start: Failed to init external RAM!

Have not analyzed the kit hardware connections in detail.
Should SPI RAM hardware on this kit work straight out of the box?

Thanks

[loboris]

...Trying to build firmware for esp-wrover-kit to use SPI-RAM...
...Should SPI RAM hardware on this kit work straight out of the box?

There are two versions of ESP-WROVER-KIT:
with ESP-WROOM-32 module (without psRAM)


with ESP32-WROVER module (with 4MB psRAM).


If your board has ESP-WROOM-32 module , the SPI-RAM cannot be used, as it does not exist.

[EasyRider]

Thanks Boris

That's it, trap for uninitiated. Wrover kit with wroom module???

I have stand alone wrover modules that I can replace the wroom.
Looks like solder pad footprint is in place for wrover, I hope that it doesn't need any other support components.
Now for a bit of unsoldering fun without lifting the pads.

Regards

[loboris]

@EasyRider

You can replace ESP-WROOM32 with ESP32-WROVER, be careful, the board has large ground plane and a lot of heat has to be applied, you can damage the display and easily desolder some resistors/capacitors around the module.

[EasyRider]

Sorry to pester you with noob questions Boris.

I have just started playing with your esp32 Micropython port and will take a while to understand BUILD menuconfig options.

Since my Wrover kit came with Wroom module installed and I tried to build firmware with external SPI RAM which didn't work for obvious reasons.

I am now trying to reconfigure (go back) to build firmware for standard esp32 configuration that does not boot.
Obviously I have missed something in the configuration that I don't understand at the moment.

If I can make a suggestion to include menuconfig option for new players like myself.
If possible to include an option for "default" setups for both standard esp32 and with SPI RAM, so that "sort of standard working firmware" can be built without having to tweak heap memory, partitions, buffers etc. settings?

This is the failed boot log for standard esp32 after the SPI RAM option and possibly some others have been disabled/changed.

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5800
load:0x40078000,len:0
ho 12 tail 0 room 4
load:0x40078000,len:13776
entry 0x40079030
I (74) boot: Detected ESP32
I (33) boot: ESP-IDF v3.0-dev-1117-gabacf8d2 2nd stage bootloader
I (33) boot: compile time 07:21:26
I (34) boot: Enabling RNG early entropy source...
I (40) boot: SPI Speed : 40MHz
I (44) boot: SPI Mode : DIO
I (48) boot: SPI Flash Size : 4MB
I (52) boot: Partition Table:
I (56) boot: ## Label Usage Type ST Offset Length
I (63) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (70) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (78) boot: 2 MicroPython factory app 00 00 00010000 00270000
I (85) boot: 3 internalfs Unknown data 01 81 00280000 00140000
I (93) boot: End of partition table
I (97) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x47080 (29p
I (163) esp_image: segment 1: paddr=0x000570a8 vaddr=0x3ffb0000 size=0x076b0 ( d
I (170) esp_image: segment 2: paddr=0x0005e760 vaddr=0x40080000 size=0x00400 ( d
I (170) esp_image: segment 3: paddr=0x0005eb68 vaddr=0x40080400 size=0x014a8 ( d
I (180) esp_image: segment 4: paddr=0x00060018 vaddr=0x400d0018 size=0xbc308 (7p
I (339) esp_image: segment 5: paddr=0x0011c328 vaddr=0x400818a8 size=0x13600 ( d
I (357) esp_image: segment 6: paddr=0x0012f930 vaddr=0x400c0000 size=0x00064 ( d
I (357) esp_image: segment 7: paddr=0x0012f99c vaddr=0x50000000 size=0x00904 ( d
I (369) boot: Loaded app from partition at offset 0x10000
I (369) boot: Disabling RNG early entropy source...
I (375) cpu_start: Pro cpu up.
I (379) cpu_start: Starting app cpu, entry point is 0x40081228
I (0) cpu_start: App cpu up.
I (389) heap_init: Initializing. RAM available for dynamic allocation:
D (396) heap_init: New heap initialised at 0x3ffae6e0
I (401) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
D (407) heap_init: New heap initialised at 0x3ffc5f68
I (412) heap_init: At 3FFC5F68 len 0001A098 (104 KiB): DRAM
I (419) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (425) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
D (431) heap_init: New heap initialised at 0x40094ea8
I (436) heap_init: At 40094EA8 len 0000B158 (44 KiB): IRAM
I (443) cpu_start: Pro cpu start user code
D (455) clk: RTC_SLOW_CLK calibration value: 3382400
D (17) intr_alloc: Connected src 46 to int 2 (cpu 0)
D (17) intr_alloc: Connected src 57 to int 3 (cpu 0)
D (18) intr_alloc: Connected src 16 to int 9 (cpu 0)
D (22) intr_alloc: Connected src 24 to int 12 (cpu 0)
I (28) cpu_start: Starting scheduler on PRO CPU.
D (0) intr_alloc: Connected src 25 to int 2 (cpu 1)
I (4) cpu_start: Starting scheduler on APP CPU.
D (52) heap_init: New heap initialised at 0x3ffe0440
D (58) heap_init: New heap initialised at 0x3ffe4350
D (63) nvs: nvs_flash_init_custom partition=nvs start=9 count=6
Error allocating heap, Halted.

[EasyRider]

Have reduced heap allocation of 125K to 80K and is working for now.

[devnull]

[/quote]
This is caused by the ESP32 rev. 0 chip bug:

Thanks, but this happens on both my ESP32WROOM modules which were received about 6 months ago and could be REV:0, and ES32WROVER Module which was received a few weeks ago, I doubt that the new WROVER is still using REV:0 chips ?!

But how can I tell if they are REV 0 or 1 - I see there is a fuse setting, is it possible to read this fuse setting inside micropython otherwise there appears to be no way to tell ?!

Interestingly, the WROVER always shows the WDT RESET, but the WROOM only shows it intermittently.

The extra delay is set to 2000us but this does not appear to fixit:

Code: Select all

(2000) Extra delay in deep sleep wake stub (in us)

[loboris]

ESP32 revision is reported when flashing the chip:

Code: Select all

Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.1
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
...
...

RTC WDT reset is reported only when reseting with RESET button. POWERON_RESET is detected, then there is Flash read error and the chip is reset by WDT.

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371 
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6240
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:15660
entry 0x400790b4
....
....
 Reset reason: RTC WDT reset

Interestingly, when the board is reset by esp-idf monitor, the Poweron reset is reported. It looks like WDT reset is caused by some condition when only the reset (EN) pin is activated.

Code: Select all

--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6240
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:15660
entry 0x400790b4
....
....

 Reset reason: Power on reset

Reset after deep sleep is reported correctly:

Code: Select all

>>> import machine
>>> machine.deepsleep(10000)
ESP32: DEEP SLEEP
ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:6240
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:15660
entry 0x400790b4
....
....
 
 Reset reason: Deepsleep wake-up
Wakeup source: RTC wake-up

Also, the software reset is reported correctly:

Code: Select all

>>> import machine
>>> machine.reset()
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5904
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:13876
entry 0x40079070
I....
.....
 Reset reason: Soft CPU reset

[jimwims]

I am running this MicroPython port on an ESP WROVER Kit v 3. I have a sketch which makes two urequests.get() calls, receives the jason responses, extracts the desired information and writes it to the tft display. This is repeated every ten minutes in a "while 1" loop. The sketch runs very well except that after some variable number of loops it just stops running. Today I twice counted the number of times the while loop repeated before it stopped running -- 16 on the first try and 29 on the second.

Threads on this forum relating to the ESP8266 suggest this failure may be explained by failing to close the responses at the end of the loop. I have tried including a response.close() for each of the responses before the end of the loop. This just gives me the error message "line 46, in getweather\r\nAttributeError: \'dict\' object has no attribute \'close\'\r\n')". Line 46 is the location of the first response.close().

I am a novice at this and have spent a lot of time trying to figure out what might be causing my problem and how I can avoid it. Any suggestions would be appreciated.

Thank you for all the work that has gone into this port. I very much appreciate it!

Jim