Bad restart with esp_restart()

kostyan5
Posts: 50
Joined: Mon Mar 06, 2017 3:16 pm

Bad restart with esp_restart()

Postby kostyan5 » Sat May 06, 2017 2:55 pm

When calling esp_restart() most of the time CPU reboots with SW_CPU_RESET. However, sometimes before booting up it restarts an extra time with RTCWDT_RTC_RESET. It doesn't happen every time, maybe 1 out of 5. Log below shows 1 "good" restart followed by
a "bad" restart. This presents a problem because RTCWDT_RTC_RESET resets real time clock. I'm using ESP32 Thing from sparkfun.
The code used to test this is simple:

Code: Select all

void app_main(void)
{
    esp_restart();
}

Code: Select all

rst:0xc (SW_CPU_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:3448
load:0x40078000,len:10388
load:0x40080000,len:252
0x40080000: _iram_start at ??:?

entry 0x40080034
0x40080034: _iram_start at ??:?

I (550) cpu_start: Pro cpu up.
I (551) cpu_start: Single core mode
I (552) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (564) heap_alloc_caps: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (584) heap_alloc_caps: At 3FFC5880 len 0001A780 (105 KiB): DRAM
I (605) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (626) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (647) heap_alloc_caps: At 400929D8 len 0000D628 (53 KiB): IRAM
I (668) 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)
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:3448
load:0x40078000,len:10388
load:0x40080000,len:252
0x40080000: _iram_start at ??:?

entry 0x40080034
0x40080034: _iram_start at ??:?

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:3448
load:0x40078000,len:10388
load:0x40080000,len:252
0x40080000: _iram_start at ??:?

entry 0x40080034
0x40080034: _iram_start at ??:?

I (550) cpu_start: Pro cpu up.
I (551) cpu_start: Single core mode
I (552) heap_alloc_caps: Initializing. RAM available for dynamic allocation:
I (564) heap_alloc_caps: At 3FFAFF10 len 000000F0 (0 KiB): DRAM
I (584) heap_alloc_caps: At 3FFC5880 len 0001A780 (105 KiB): DRAM
I (605) heap_alloc_caps: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM
I (626) heap_alloc_caps: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (647) heap_alloc_caps: At 400929D8 len 0000D628 (53 KiB): IRAM
I (668) cpu_start: Pro cpu start user code

User avatar
martinayotte
Posts: 141
Joined: Fri Nov 13, 2015 4:27 pm

Re: Bad restart with esp_restart()

Postby martinayotte » Sat May 06, 2017 9:32 pm

I think it is related to the v0 silicon bug that Igrr is describing in this comment.
He said that it should be fixed in v1 silicon ...
https://github.com/espressif/esp-idf/is ... -291916959

kostyan5
Posts: 50
Joined: Mon Mar 06, 2017 3:16 pm

Re: Bad restart with esp_restart()

Postby kostyan5 » Sat May 06, 2017 9:34 pm

Thanks! That sounds like my problem. When I source these parts, how do I make sure I get v1? What's the specific part #?

WiFive
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

Re: Bad restart with esp_restart()

Postby WiFive » Sat May 06, 2017 9:43 pm

martinayotte wrote:I think it is related to the v0 silicon bug that Igrr is describing in this comment.
He said that it should be fixed in v1 silicon ...
https://github.com/espressif/esp-idf/is ... -291916959
No I dont think this should happen with a software reset.

Possibly increase the timeout here: https://github.com/espressif/esp-idf/bl ... api.c#L250

Or reset by deep sleep wakeup.

ESP_igrr
Posts: 2071
Joined: Tue Dec 01, 2015 8:37 am

Re: Bad restart with esp_restart()

Postby ESP_igrr » Sun May 07, 2017 2:58 am

This doesn't look like the ECO bug related thing, as the startup process goes all the way to the 2nd bootloader entry, according to the log. Most likely we are having an issue switching clock to PLL. Curious thing however is that i can't reproduce this on the test board I have here. Will try a few other boards on Monday.

Who is online

Users browsing this forum: No registered users and 65 guests