ESP32 Forum

ESP32 Official Forum
http://esp32.io/

esp-idf examples fail

http://esp32.io/viewtopic.php?f=13&t=2778

Page 1 of 1

esp-idf examples fail

Posted: Tue Aug 22, 2017 12:48 am
by rezarethink
I'm able to flash binaries using the esp gui tool that others have built but using the esp-idf 'make flash' results in a binary that doesn't boot. For example, this is what I see with hello_world:
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:4
load:0x3fff0010,len:4
load:0x3fff0014,len:5436
load:0x40078000,len:0
load:0x40078000,len:12028
entry 0x40078f24
I (33) boot: ESP-IDF v3.0-dev-317-gfc85cb68 2nd stage bootloader
I (33) boot: compile time 17:30:46
I (33) boot: Enabling RNG early entropy source...
I (50) boot: SPI Speed : 20MHz
I (63) boot: SPI Mode : DIO
I (75) boot: SPI Flash Size : 8MB
I (88) boot: Partition Table:
I (99) boot: ## Label Usage Type ST Offset Length
I (121) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (145) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (168) boot: 2 factory factory app 00 00 00010000 00100000
I (191) boot: End of partition table
I (204) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0309c ( 1 2444) map
I (250) esp_image: segment 1: paddr=0x000130c4 vaddr=0x3ffb0000 size=0x016e0 ( 5856) load
I (268) esp_image: segment 2: paddr=0x000147ac vaddr=0x40080000 size=0x00400 ( 1024) load
I (288) esp_image: segment 3: paddr=0x00014bb4 vaddr=0x40080400 size=0x06ba8 ( 2 7560) load
I (359) esp_image: segment 4: paddr=0x0001b764 vaddr=0x400c0000 size=0x00000 ( 0) load
I (360) esp_image: segment 5: paddr=0x0001b76c vaddr=0x00000000 size=0x048a4 ( 1 8596)
I (406) esp_image: segment 6: paddr=0x00020018 vaddr=0x400d0018 size=0x0d0cc ( 5 3452) map
I (496) boot: Loaded app from partition at offset 0x10000
I (497) boot: Disabling RNG early entropy source...
I (498) cpu_start: Pro cpu up.
I (509) cpu_start: Single core mode
I (524) heap_init: Initializing. RAM available for dynamic allocation:
I (544) heap_init: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (563) heap_init: At 3FFB1E28 len 0002E1D8 (184 KiB): DRAM
I (582) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (601) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (621) heap_init: At 40086FA8 len 00019058 (100 KiB): IRAM
I (641) cpu_start: Pro cpu start user code
ets Jun 8 2016 00:22:57

....REBOOTS & REPEATS....
Looks like the application keeps rebooting...

Couple comments:

I followed the instructions here http://esp-idf.readthedocs.io/en/latest ... setup.html but it doesn't setup python. I found the old instructions of setting up python here: https://github.com/espressif/esp-idf/issues/200

this version of python uses the /dev/ttyS(COM PORT - 1) serial ports rather than direct COM ports. Seemed to flash fine though - not sure what needs to happen to use serial ports in the COMx format.

I tried setting freertos to single cpu mode as well - still reboots as soon as it hits the code. The code seems to compile fine, uploads fine. Not sure what could be causing the issue(s)...

Thanks in advance!
Reza

Re: esp-idf examples fail

Posted: Tue Aug 22, 2017 2:34 am
by ESP_Angus
Hi Reza,

Does it reboot immediately or after 10 seconds? I'm asking because the behaviour of the "hello world" example is to print some output on stdout, and then reboot after 10 seconds.

It looks like output stops at the time the FreeRTOS scheduler starts running. It's possible this is because of some configuration change in the app "sdkconfig". If you delete the sdkconfig and use a default one (changing only the serial port, or you can override on the command line with "make flash ESPPORT=COMx") then do you see any more output?

Angus

Re: esp-idf examples fail

Posted: Tue Aug 22, 2017 2:37 am
by ESP_Angus
Hi Reza,

Does it reboot immediately or after 10 seconds? I'm asking because the behaviour of the "hello world" example is to print some output on stdout, and then reboot after 10 seconds.

It looks like output stops at the time the FreeRTOS scheduler starts running. It's possible this is because of some configuration change in the app "sdkconfig". If you delete the sdkconfig file from the example directory and use a default one (changing only the serial port, or you can override on the command line with "make flash ESPPORT=/dev/ttySx") then do you see any more output?
I followed the instructions here http://esp-idf.readthedocs.io/en/latest ... setup.html but it doesn't setup python. I found the old instructions of setting up python here: https://github.com/espressif/esp-idf/issues/200
It sounds like maybe you are running "msys.exe" rather than "mingw32.exe", which will cause MSYS2 to not see the python interpreter. If you're happy with the setup you have then there's no reason to change it, I don't think that's related to the problem you're seeing here.
this version of python uses the /dev/ttyS(COM PORT - 1) serial ports rather than direct COM ports. Seemed to flash fine though - not sure what needs to happen to use serial ports in the COMx format.
To use serial ports in the Windows "COMx" format then you need to use "mingw32.exe" not "msys.exe", in which case you get a different version of Python (MINGW that we supply rather than the MSYS verison you've installed yourself.) As I said above, though, feel free to keep using what you have.

Angus

Re: esp-idf examples fail

Posted: Tue Aug 22, 2017 3:01 am
by rezarethink
Thanks for the prompt answer.

You were right, the issue was my running msys2 not mingw32.exe with the missing python.

I re-installed a fresh copy of the IDE on a new machine and ran mingw32.exe. I built hello_world. Did a make erase_flash and make flash. The output is slightly more verbose... These lines are new:
0x40080000: _iram_start at ??:?
...
0x400d0018: _flash_cache_start at ??:?
...
0x40080d00: call_start_cpu1 at C:/msys32/home/reza/esp/esp-idf/components/esp32/cpu_start.c:192
And it does reboot instantly.

I was able to upload the ESP-AT precompiled binaries onto this board and it worked fine, so I don't think it's the hardware. Could there be a bug in the latest GIT code? Is there a snapshot of the IDF that is known to work?

Here's the full output....
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:0x3fff0010,len:4
load:0x3fff0014,len:5428
load:0x40078000,len:0
load:0x40078000,len:12028
entry 0x40078f24
I (30) boot: ESP-IDF v3.0-dev-317-gfc85cb68 2nd stage bootloader
I (30) boot: compile time 19:45:34
I (30) boot: Enabling RNG early entropy source...
I (47) boot: SPI Speed : 40MHz
I (60) boot: SPI Mode : DIO
I (72) boot: SPI Flash Size : 8MB
I (85) boot: Partition Table:
I (96) boot: ## Label Usage Type ST Offset Length
I (118) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (141) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (165) boot: 2 factory factory app 00 00 00010000 00100000
I (188) boot: End of partition table
I (201) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x035c0 ( 13760) map
I (244) esp_image: segment 1: paddr=0x000135e8 vaddr=0x3ffb0000 size=0x01ee4 ( 7908) load
I (266) esp_image: segment 2: paddr=0x000154d4 vaddr=0x40080000 size=0x00400 ( 1024) load
0x40080000: _iram_start at ??:?

I (285) esp_image: segment 3: paddr=0x000158dc vaddr=0x40080400 size=0x07280 ( 29312) load
I (348) esp_image: segment 4: paddr=0x0001cb64 vaddr=0x400c0000 size=0x00000 ( 0) load
I (349) esp_image: segment 5: paddr=0x0001cb6c vaddr=0x00000000 size=0x034a4 ( 13476)
I (386) esp_image: segment 6: paddr=0x00020018 vaddr=0x400d0018 size=0x0d2f4 ( 54004) map
0x400d0018: _flash_cache_start at ??:?

I (471) boot: Loaded app from partition at offset 0x10000
I (471) boot: Disabling RNG early entropy source...
I (472) cpu_start: Pro cpu up.
I (484) cpu_start: Starting app cpu, entry point is 0x40080d00
0x40080d00: call_start_cpu1 at C:/msys32/home/reza/esp/esp-idf/components/esp32/cpu_start.c:192

I (504) cpu_start: App cpu up.
I (517) heap_init: Initializing. RAM available for dynamic allocation:
I (537) heap_init: At 3FFAE2A0 len 00001D60 (7 KiB): DRAM
I (556) heap_init: At 3FFB26A0 len 0002D960 (182 KiB): DRAM
I (575) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (595) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (615) heap_init: At 40087680 len 00018980 (98 KiB): IRAM
I (634) cpu_start: Pro cpu start user code
ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

Re: esp-idf examples fail

Posted: Tue Aug 22, 2017 3:04 am
by rezarethink
Also, I made no changes outside of the serial settings in this new installation so sdkconfig should be clean...

Finally, I don't have a RTC 32k xtal hooked up -- not sure if it's required for FREERTOS to run.

Thanks,
Reza

*SOLVED* Re: esp-idf examples fail

Posted: Tue Aug 22, 2017 3:51 am
by rezarethink
*SOLVED*

Based on the datasheets, the minimum voltage is 2.3V. I'm trying to deploy in a low-power environment so I use a buck regulator putting out 2.4V at 500mA. This worked fine for whatever application was running on the device previously, so I thought it would be sufficient (I removed a flash chip off a sparkfun board and used that for testing, and the application worked fine). And that application is wifi-based.

For some reason, this hello_world example app uses more power or something and it was drawing too much current and causing the board to reboot when the application started. I switched over to a 300mA 3.0V LDO and now it works fine.

Any idea why this app would draw more current causing a reboot? Seems very strange...

Re: *SOLVED* Re: esp-idf examples fail

Posted: Tue Aug 22, 2017 4:17 am
by ESP_Angus
rezarethink wrote: For some reason, this hello_world example app uses more power or something and it was drawing too much current and causing the board to reboot when the application started. I switched over to a 300mA 3.0V LDO and now it works fine.

Any idea why this app would draw more current causing a reboot? Seems very strange...
In recent IDF versions the brownout detector is set to 2.5V. You can change it (higher, lower or disabled) under Component Config -> ESP32 Specific.

There should be some output from the brownout detector when it triggers a reset, though. This may be a bug.
All times are UTC
Page 1 of 1
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/