Core board OK, naked wroom-32 bad - what am I missing?

[eyaleb]

I am using a core board which works OK. I now received a few ESP-32S modules and tried the same app.

I connected only 4 pins (vcc, gnd, tx, rx) and had no issue programming it and running the hello_world example.
I then flashed my app and it is dying at the 'esp_wifi_connect()'.

Two modules have the same issue.
I tried the 'http_request' example and got the same crash.

Are there other pins that need attention?

This is what the crash looks like, messages from the app are time-stamped, the Exception happens immediately after the 'esp_wifi_connect'.

There is a 1s delay just before, to confirm that the crash does not happen due to something else. Note how the app is paused after the SYSTEM_EVENT_STA_START event was delivered.

Code: Select all

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0x00
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0008,len:8
load:0x3fff0010,len:4404
load:0x40078000,len:11092
load:0x40080000,len:252
entry 0x40080034
I (45) boot: ESP-IDF v2.0-rc1-902-ge45a288-dirty 2nd stage bootloader
I (45) boot: compile time 00:29:53
I (48) boot: Enabling RNG early entropy source...
I (65) boot: SPI Speed      : 40MHz
I (77) boot: SPI Mode       : DIO
I (90) boot: SPI Flash Size : 4MB
I (102) boot: Partition Table:
I (113) boot: ## Label            Usage          Type ST Offset   Length
I (136) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (159) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (182) boot:  2 factory          factory app      00 00 00010000 00100000
I (206) boot: End of partition table
I (219) boot: Disabling RNG early entropy source...
I (236) boot: Loading app partition at offset 00010000
I (1023) boot: segment 0: paddr=0x00010018 vaddr=0x00000000 size=0x0ffe8 ( 65512)
I (1024) boot: segment 1: paddr=0x00020008 vaddr=0x3f400010 size=0x0b188 ( 45448) map
I (1040) boot: segment 2: paddr=0x0002b198 vaddr=0x3ffb0000 size=0x02b24 ( 11044) load
I (1071) boot: segment 3: paddr=0x0002dcc4 vaddr=0x40080000 size=0x00400 (  1024) load
I (1094) boot: segment 4: paddr=0x0002e0cc vaddr=0x40080400 size=0x131d4 ( 78292) load
I (1157) boot: segment 5: paddr=0x000412a8 vaddr=0x400c0000 size=0x00064 (   100) load
I (1158) boot: segment 6: paddr=0x00041314 vaddr=0x00000000 size=0x0ecf4 ( 60660)
I (1178) boot: segment 7: paddr=0x00050010 vaddr=0x400d0018 size=0x464ec (287980) map
I (1205) boot: segment 8: paddr=0x00096504 vaddr=0x50000000 size=0x00034 (    52) load
I (1231) cpu_start: Pro cpu up.
I (1242) cpu_start: Starting app cpu, entry point is 0x40080fa8
I (0) cpu_start: App cpu up.
I (1275) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (1298) heap_alloc_caps: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (1318) heap_alloc_caps: At 3FFB7B60 len 000284A0 (161 KiB): DRAM
I (1339) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (1361) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1382) heap_alloc_caps: At 400935D4 len 0000CA2C (50 KiB): IRAM
I (1403) cpu_start: Pro cpu start user code
I (1464) cpu_start: Starting scheduler on PRO CPU.
I (207) cpu_start: Starting scheduler on APP CPU.
  0.000433 Chip revision 0
  0.002967 tcpip_adapter_init
  0.005827 tcpip_adapter_dhcpc_stop
  0.008897 tcpip_adapter_set_ip_info
  0.012260 esp_event_loop_init
  0.014847 esp_wifi_init
I (217) wifi: wifi firmware version: 9bf11be
I (217) wifi: config NVS flash: enabled
I (217) wifi: config nano formating: disabled
I (217) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (227) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (247) wifi: Init dynamic tx buffer num: 32
I (247) wifi: Init dynamic rx buffer num: 32
I (247) wifi: wifi driver task: 3ffc076c, prio:23, stack:4096
I (257) wifi: Init static rx buffer num: 10
I (257) wifi: Init dynamic rx buffer num: 32
I (267) wifi: Init rx ampdu len mblock:7
I (267) wifi: Init lldesc rx ampdu entry mblock:4
I (267) wifi: wifi power manager task: 0x3ffc5b34 prio: 21 stack: 2560
  0.094313 ### /data/esp32/udp/main/./udp.c:573: LOG
  0.098822 esp_wifi_set_mode
  0.101678 esp_wifi_set_config
  0.104337 ### /data/esp32/udp/main/./udp.c:588: LOG
  0.108891 esp_wifi_start
I (297) wifi: wifi timer task: 3ffc6bb4, prio:22, stack:3584
I (357) phy: phy_version: 355.0, 2888565, May 23 2017, 16:12:06, 0, 0
I (357) wifi: mode : sta (30:ae:a4:xx:xx:xx)
  0.174976 event_handler: SYSTEM_EVENT 2
  0.176486 SYSTEM_EVENT_STA_START
  1.169836 esp_wifi_connect
Guru Meditation Error of type IllegalInstruction occurred on core  0. Exception was unhandled.
Register dump:
PC      : 0x400eb181  PS      : 0x00060630  A0      : 0x800e52d7  A1      : 0x3ffc0650
A2      : 0x3ffc723c  A3      : 0x00000002  A4      : 0xdeadbeef  A5      : 0xdeadbeef
A6      : 0x00000000  A7      : 0x3ffb30b8  A8      : 0x800eb17e  A9      : 0x3ffc0630
A10     : 0x46b33c8c  A11     : 0x400822bc  A12     : 0x00060823  A13     : 0x3ffc06d8
A14     : 0x00000010  A15     : 0x00000000  SAR     : 0x0000001e  EXCCAUSE: 0x00000000
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff

Backtrace: 0x400eb181:0x3ffc0650 0x400e52d7:0x3ffc0690 0x400e7079:0x3ffc06c0

Rebooting...

[sintech]

Probably it can be power issues.
Check that you 3.3v source can provide at least 250mA.

[eyaleb]

It is fed directly by a USB<->TTL module that never had an issue.
[later] Nevertheless, now attached to a proper power supply it works. Also works with a LiFePO4 battery (no LDO). I will now measure the power usage...
I feel stupid for not testing this first...

[later] It peaks at around 480mA, which is much more than I expected, and explains the problem I had.

[eyaleb]

The doco (https://www.espressif.com/sites/default ... eet_en.pdf,version 1.8, page 8) suggests power usage with WiFi should be "160 ~ 260 mA". This is not what I see.

[img]

ESP-WROOM-32 power usage

power-usage.png (36.37 KiB) Viewed 14291 times

[/img]

472mA is what I typically see. The circuit is trivial, using a LiFePO4 battery (3.3v measured) and a DSO:

Code: Select all

Battery GND -> 1R ->ESP GND
Batter 3.3v -> ESP Vcc
DSO ch4 attached across the resistor.
DSO ch2 attached to GPIO5 which naturally goes high when the esp wakes up (the trigger).

BTW, this app runs in around 1.4s. On the esp8266 it takes only 0.4s. I try to keep the code as similar as possible.
The bulk of the time is spent in esp_wifi_init and esp_wifi_connect (static ip!). Messages are prefixed with a time-stamp.

Code: Select all

  0.014841 esp_wifi_init
  0.094551 esp_wifi_start
  0.113538 esp_wifi_connect
  0.114174 event_handler: SYSTEM_EVENT 2
  0.119473 SYSTEM_EVENT_STA_START
I (407) wifi: n:11 0, o:1 0, ap:255 255, sta:11 0, prof:1
I (1067) wifi: state: init -> auth (b0)
I (1067) wifi: state: auth -> assoc (0)
I (1077) wifi: state: assoc -> run (10)
I (1087) wifi: connected with eyal, channel 11
  0.961878 event_handler: SYSTEM_EVENT 4
  0.962485 SYSTEM_EVENT_STA_CONNECTED rssi=-71
  

cheers

[sintech]

It is fed directly by a USB<->TTL module that never had an issue.

That was my problem too.
The peaks in power consumption that you observe might be caused by wifi calibration process.

[MalteJ]

Somewhere was mentioned that a 3,3V power supply with 500mA is recommended when using WiFi.

[eyaleb]

Does anyone know how I tell the esp32 to not do calibration?

TIA

[ESP_Angus]

Does anyone know how I tell the esp32 to not do calibration?

Under menuconfig -> Components -> ESP32-Specific there is an option "Do phy calibration and store calibration data in NVS". If you disable this then calibration is not performed. We don't recommend disabling this option, except for testing.

When this option is enabled, PHY calibration data is stored as part of the NVS (non-volatile-storage) partition of the flash.

The default calibration logic (if the "Do phy calibration" option is enabled) can be found here:
https://github.com/espressif/esp-idf/bl ... nit.c#L264

The logic is:
- If no valid calibration is saved in NVS then perform a full calibration (power intensive) and save it.
- Otherwise, if waking from deep sleep then perform no calibration.
- In all other cases, perform a (faster, less power intensive) partial calibration based on the data in NVS, then save the updated calibration.

[eyaleb]

This is what I thought but found it to not reduce the power usage, so it has been disabled in my project (https://github.com/makehackvoid/ESP8266 ... main/udp.c).

I hoped that there is a way, as on the esp8266, to select calibration mode for the next wakeup. I planned to do a full calibration once in a long while as my projects run for months of battery, waking up periodically.

I asked because a comment in this thread suggested that the calibration is the reason for the high current peaks. This seems to not be the case as I see current peaks at times as high as 500mA+ on wakeup.

Right now, with a call to esp_phy_load_cal_and_init() enabled, I still see 460-480mA max, with a steady 145mA for most of the cycle. Same as without the call. A bit much, so maybe I should stay with the '8266 and check the '32 again later?

cheers