Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

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

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby ESP_igrr » Wed Dec 05, 2018 1:40 am

Upon further thought, RTC WDT might be happening because the bootloader eventually disables the TG WDT, and keeps only RTC WDT running. So might not be related to bootloader_clock_configure.

deandob
Posts: 14
Joined: Sun Dec 02, 2018 5:21 am

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby deandob » Wed Dec 05, 2018 3:19 am

Hi ESP_igrr,

Patched the bootloader with console messages & delays, it looks to crash at the bootloader_clock_configure(); function (previous line is a console message & displayed, line after clock_configure is also a console message but isn't displayed.

Also - do have a look at the PDF here: https://1drv.ms/b/s!ApUB68SilQqFhuMzLHlyS3dn1-D2HA
The oscilloscope waveforms for the internal flash definitely don't look right. GPIO17 and CLK especially. SD1 also doesn't look right but it is hitting the resolution limits of my digital scope.

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

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby ESP_igrr » Wed Dec 05, 2018 4:22 am

Okay, can you try changing "int cpu_freq_mhz = 80;" to "int cpu_freq_mhz = 40;" in bootloader_clock.c, and see if that allows the 2nd stage bootloader to proceed past "bootloader_clock_configure()"?

deandob
Posts: 14
Joined: Sun Dec 02, 2018 5:21 am

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby deandob » Wed Dec 05, 2018 4:54 am

Its working now at the slower clock speed. Question is why?
- Bad chip batch => possible
- Fault chip due to overheating soldering => possible but the flashing works and I have 2 boards with same symptoms
- Poor PCB layout => unlikely as the frequency sensitive parts are inside the SIP (I do have the SMPS somewhat close to the PICO but has a ground plane underneath + earth / VCC lines between SWPS and PICO)

Any ideas on how to rectify?

Here is the output:
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, 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:0x3fff0018,len:4
load:0x3fff001c,len:8904
load:0x40078000,len:10788
load:0x40080400,len:7068
entry 0x400807bc
[0;31mE (94) boot: in bootloader_main[0m
[0;31mE (105) boot: after vddsdio_configure[0m
[0;31mE (115) boot: after bootloader_read_flash_id()[0m
D (126) bootloader_flash: mmu set block paddr=0x00000000 (was 0xffffffff)[0m
[0;31mE (130) boot: after bootloader_flash_read[0m
[0;31mE (154) boot: after flash_gpio_configure[0m
[0;31mE (194) boot: after bootloader_clock_configure[0m
[0;31mE (215) boot: after uart_console_configure[0m
[0;31mE (225) boot: after wdt_reset_check[0m
[0;32mI (235) boot: ESP-IDF v3.3-dev-206-g0d7f2d77c-dirty 2nd stage bootloader[0m
[0;32mI (237) boot: compile time 13:06:47[0m
[0;32mI (250) boot: Enabling RNG early entropy source...[0m
D (267) boot: magic e9[0m
D (274) boot: segments 04[0m
D (282) boot: spi_mode 02[0m
D (291) boot: spi_speed 02[0m
D (299) boot: spi_size 02[0m
[0;32mI (308) boot: SPI Speed : 20MHz[0m
[0;32mI (321) boot: SPI Mode : DIO[0m
[0;32mI (333) boot: SPI Flash Size : 4MB[0m
D (346) bootloader_flash: mmu set paddr=00000000 count=1[0m
D (362) boot: mapped partition table 0x8000 at 0x3f408000[0m
D (380) flash_parts: partition table verified, 4 entries[0m
[0;32mI (396) boot: Partition Table:[0m
[0;32mI (407) boot: ## Label Usage Type ST Offset Length[0m
D (430) boot: load partition table entry 0x3f408000[0m
D (445) boot: type=1 subtype=2[0m
[0;32mI (455) boot: 0 nvs WiFi data 01 02 00009000 00006000[0m
D (478) boot: load partition table entry 0x3f408020[0m
D (493) boot: type=1 subtype=1[0m
[0;32mI (503) boot: 1 phy_init RF data 01 01 0000f000 00001000[0m
D (526) boot: load partition table entry 0x3f408040[0m
D (541) boot: type=0 subtype=0[0m
[0;32mI (551) boot: 2 factory factory app 00 00 00010000 00100000[0m
[0;32mI (574) boot: End of partition table[0m
D (587) boot: Trying partition index -1 offs 0x10000 size 0x100000[0m
D (606) esp_image: reading image header @ 0x10000[0m
D (621) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
D (642) esp_image: image header: 0xe9 0x0c 0x02 0x02 40080eec[0m
V (660) esp_image: loading segment header 0 at offset 0x10018[0m
V (678) esp_image: segment data length 0x76e8 data starts 0x10020[0m
V (697) esp_image: segment 0 map_segment 1 segment_data_offs 0x10020 load_addr 0x3f400020[0m
[0;32mI (722) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x076e8 ( 30440) map[0m
D (750) bootloader_flash: mmu set paddr=00010000 count=1[0m
V (855) esp_image: loading segment header 1 at offset 0x17708[0m
D (856) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
V (860) esp_image: segment data length 0x0 data starts 0x17710[0m
V (878) esp_image: segment 1 map_segment 0 segment_data_offs 0x17710 load_addr 0x3ff80000[0m
[0;32mI (903) esp_image: segment 1: paddr=0x00017710 vaddr=0x3ff80000 size=0x00000 ( 0) load[0m
D (931) bootloader_flash: mmu set paddr=00010000 count=1[0m
V (948) esp_image: loading segment header 2 at offset 0x17710[0m
D (965) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
V (986) esp_image: segment data length 0x0 data starts 0x17718[0m
V (1004) esp_image: segment 2 map_segment 0 segment_data_offs 0x17718 load_addr 0x3ff80000[0m
[0;32mI (1030) esp_image: segment 2: paddr=0x00017718 vaddr=0x3ff80000 size=0x00000 ( 0) load[0m
D (1058) bootloader_flash: mmu set paddr=00010000 count=1[0m
V (1075) esp_image: loading segment header 3 at offset 0x17718[0m
D (1093) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
V (1114) esp_image: segment data length 0x1e98 data starts 0x17720[0m
V (1133) esp_image: segment 3 map_segment 0 segment_data_offs 0x17720 load_addr 0x3ffb0000[0m
[0;32mI (1159) esp_image: segment 3: paddr=0x00017720 vaddr=0x3ffb0000 size=0x01e98 ( 7832) load[0m
D (1187) bootloader_flash: mmu set paddr=00010000 count=1[0m
V (1228) esp_image: loading segment header 4 at offset 0x195b8[0m
D (1229) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
V (1243) esp_image: segment data length 0x0 data starts 0x195c0[0m
V (1261) esp_image: segment 4 map_segment 0 segment_data_offs 0x195c0 load_addr 0x3ffb1e98[0m
[0;32mI (1287) esp_image: segment 4: paddr=0x000195c0 vaddr=0x3ffb1e98 size=0x00000 ( 0) load[0m
D (1315) bootloader_flash: mmu set paddr=00010000 count=1[0m
V (1332) esp_image: loading segment header 5 at offset 0x195c0[0m
D (1350) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
V (1371) esp_image: segment data length 0x400 data starts 0x195c8[0m
V (1390) esp_image: segment 5 map_segment 0 segment_data_offs 0x195c8 load_addr 0x40080000[0m
[0;32mI (1416) esp_image: segment 5: paddr=0x000195c8 vaddr=0x40080000 size=0x00400 ( 1024) load[0m
D (1444) bootloader_flash: mmu set paddr=00010000 count=1[0m
V (1464) esp_image: loading segment header 6 at offset 0x199c8[0m
D (1479) bootloader_flash: mmu set block paddr=0x00010000 (was 0xffffffff)[0m
V (1500) esp_image: segment data length 0x6640 data starts 0x199d0[0m
V (1519) esp_image: segment 6 map_segment 0 segment_data_offs 0x199d0 load_addr 0x40080400[0m
[0;32mI (1545) esp_image: segment 6: paddr=0x000199d0 vaddr=0x40080400 size=0x06640 ( 26176) load[0m
D (1573) bootloader_flash: mmu set paddr=00010000 count=2[0m
V (1676) esp_image: loading segment header 7 at offset 0x20010[0m
D (1677) bootloader_flash: mmu set block paddr=0x00020000 (was 0xffffffff)[0m
V (1681) esp_image: segment data length 0x124b4 data starts 0x20018[0m
V (1700) esp_image: segment 7 map_segment 1 segment_data_offs 0x20018 load_addr 0x400d0018[0m
[0;32mI (1726) esp_image: segment 7: paddr=0x00020018 vaddr=0x400d0018 size=0x124b4 ( 74932) map[0m
D (1754) bootloader_flash: mmu set paddr=00020000 count=2[0m
V (1987) esp_image: loading segment header 8 at offset 0x324cc[0m
D (1988) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)[0m
V (1992) esp_image: segment data length 0x2a60 data starts 0x324d4[0m
V (2011) esp_image: segment 8 map_segment 0 segment_data_offs 0x324d4 load_addr 0x40086a40[0m
[0;32mI (2037) esp_image: segment 8: paddr=0x000324d4 vaddr=0x40086a40 size=0x02a60 ( 10848) load[0m
D (2064) bootloader_flash: mmu set paddr=00030000 count=1[0m
V (2117) esp_image: loading segment header 9 at offset 0x34f34[0m
D (2118) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)[0m
V (2128) esp_image: segment data length 0x0 data starts 0x34f3c[0m
V (2146) esp_image: segment 9 map_segment 0 segment_data_offs 0x34f3c load_addr 0x400c0000[0m
[0;32mI (2172) esp_image: segment 9: paddr=0x00034f3c vaddr=0x400c0000 size=0x00000 ( 0) load[0m
D (2199) bootloader_flash: mmu set paddr=00030000 count=1[0m
V (2217) esp_image: loading segment header 10 at offset 0x34f3c[0m
D (2235) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)[0m
V (2256) esp_image: segment data length 0x0 data starts 0x34f44[0m
V (2274) esp_image: segment 10 map_segment 0 segment_data_offs 0x34f44 load_addr 0x50000000[0m
[0;32mI (2300) esp_image: segment 10: paddr=0x00034f44 vaddr=0x50000000 size=0x00000 ( 0) load[0m
D (2328) bootloader_flash: mmu set paddr=00030000 count=1[0m
V (2346) esp_image: loading segment header 11 at offset 0x34f44[0m
D (2364) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)[0m
V (2385) esp_image: segment data length 0x0 data starts 0x34f4c[0m
V (2403) esp_image: segment 11 map_segment 0 segment_data_offs 0x34f4c load_addr 0x50000000[0m
[0;32mI (2429) esp_image: segment 11: paddr=0x00034f4c vaddr=0x50000000 size=0x00000 ( 0) load[0m
D (2457) bootloader_flash: mmu set paddr=00030000 count=1[0m
V (2475) esp_image: image start 0x00010000 end of last section 0x00034f4c[0m
D (2495) bootloader_flash: mmu set block paddr=0x00030000 (was 0xffffffff)[0m
D (2517) esp_image: Calculated hash: ea877f55d559861d14e2789622ce07a204f9c2367d24e94f6a6fd4c75ed1b7fd[0m
D (2545) bootloader_flash: mmu set paddr=00030000 count=1[0m
D (2563) bootloader_flash: mmu set paddr=00030000 count=1[0m
[0;32mI (2613) boot: Loaded app from partition at offset 0x10000[0m
[0;32mI (2614) boot: Disabling RNG early entropy source...[0m
D (2615) boot: Mapping segment 0 as IROM[0m
D (2628) boot: Mapping segment 7 as DROM[0m
D (2640) boot: calling set_cache_and_start_app[0m
D (2654) boot: configure drom and irom and start[0m
V (2668) boot: d mmu set paddr=00020000 vaddr=400d0000 size=74932 n=2[0m
V (2688) boot: rc=0[0m
V (2695) boot: rc=0[0m
V (2702) boot: i mmu set paddr=00010000 vaddr=3f400000 size=30440 n=1[0m
V (2722) boot: rc=0[0m
V (2728) boot: rc=0[0m
D (2735) boot: start: 0x40080eec[0m
[0;32mI (2745) cpu_start: Pro cpu up.[0m
[0;32mI (2757) cpu_start: Starting app cpu, entry point is 0x40080ea0[0m
[0;32mI (1) cpu_start: App cpu up.[0m
[0;32mI (2791) heap_init: Initializing. RAM available for dynamic allocation:[0m
[0;32mI (2811) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM[0m
[0;32mI (2829) heap_init: At 3FFB2ED8 len 0002D128 (180 KiB): DRAM[0m
[0;32mI (2849) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM[0m
[0;32mI (2869) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM[0m
[0;32mI (2889) heap_init: At 400894A0 len 00016B60 (90 KiB): IRAM[0m
[0;32mI (2909) cpu_start: Pro cpu start user code[0m

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

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby ESP_igrr » Wed Dec 05, 2018 11:15 am

Just to clarify, with the 40MHz change applied, does it boot all the way to your application, or it stops at "pro CPU start user code"?

I don't have any good explanation for this behavior, as I don't know of any reasons why clock switching might not succeed at first, but succeed later (2nd clock switch to 80/160/240 MHz happens inside the application).

Can you please check what is the CPU frequency configured for the application in menuconfig (under component config, esp32 specific)?

I'll pass this to colleagues with more hardware knowledge, and hopefully with a few more tweaks in the bootloader code we will be able to figure out the part of the process where the chip hangs up. Alternatively, if you can spare one of the non-working boards and send it to Espressif for analysis, this would also help.

deandob
Posts: 14
Joined: Sun Dec 02, 2018 5:21 am

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby deandob » Wed Dec 05, 2018 12:33 pm

Hi ESP_igrr,

It does not enter the user application but the bootloader seems to finish OK at the slower speed. CPU frequency under menuconfig is 80Mhz.

If the issue is sensitivity to CPU frequency then its likely I have a bad chip or there is some hardware interaction with the PCB, which I assumed should be minimal as the PICO is a SIP but maybe not. Its a very small form factor board (hence choosing the PICO).

I can send one of the non-working boards to Espressif, but it might be more helpful if I could speak to someone on the phone first and go over the symptoms, how to optimise my PCB etc. How can I organise this?

Thanks for the help.

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

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby ESP_igrr » Wed Dec 05, 2018 12:45 pm

Okay, if it does not enter user application then it means that it still locks up when switching the frequency, just in a different place. This makes more sense.

Indeed a power supply instability or other noise can prevent the PLL from locking.

You can contact Espressif support via sales at Espressif com, and they should be able to help. You can point them to this thread for context.

deandob
Posts: 14
Joined: Sun Dec 02, 2018 5:21 am

Re: Help needed - New ESP32 PICO D4.1 design continously looping with RTCWDT_RTC_RESET

Postby deandob » Thu Dec 06, 2018 8:27 pm

Thanks ESP_igrr. That gives me enough to work on. I'll redo the PCB with a view to better noise isolation. My thesis that the PICO would be more immune to layout / noise due to it being a SIP is likely wrong (not that I ignored the usual design rules, but I have very constrained space, in particular the SMPS is close to the PICO).

Who is online

Users browsing this forum: No registered users and 7 guests