Continuous Rebooting? #7
Comments
|
Hmm, as far as I can tell, that's the ROM trying to load the bootloader. How did you flash the app? Also, what board are you using? |
|
I flashed with esptool, via I'm using the two small form-factor boards that were sent to Hackaday as demos. They're labelled ESP_02_20160831-18 and -30. They worked fine with the SSC commands when they arrived. I didn't do anything more with the RTOS branch, because IDF looks like the way to go. FWIW, the behavior changes when I accidentally touched a few of the pins on the side near the USB connector. Playing with it intentionally just now, I can change the 2nd load address by touching any of the I don't know about the boot process, but it's starting to look like a pin should have a pullup/down or something? (Unless this is normal behavior.) If this is a one-off hardware bug, and you'd like to debug this offline, you can reach me directly: [email protected]. |
|
Well, the good thing is, I acquired one here as well. (Fyi, the boards are very new, I think they arrived a day or so before we shipped off your samples.) Looks like the flash that's on the chips uses a slightly different command to go into qio read mode. The guys testing the boards have some scripts to modify the bootloader for that, but they haven't managed to integrate it into the master branch yet. For now, a very quick hack that makes it work: modify esp-idf/components/esptool_py/Makefile.projbuild and for the line that contains 'elf2image', add '--flash_mode dio', like such:
|
|
Awesome. That by itself gets me to the single-core kernel error (#6). Disabling "Start WiFi with system startup" and enabling both cores in FreeRTOS gets me to ping. Now all I need to do is figure out something to show off with the chip for an article. Any suggestions? What's your favorite oddball feature? |
|
hi elliot, http://esp32.com/viewtopic.php?f=18&t=189 so i know, ( you are a lucky boy :) am have no board just in time on hand ) the code is right http://esp32.com/viewtopic.php?f=5&t=188#p875 direct: best wishes ps: be noted this ( it is a early doing with the esp-idf ) ..and let me ( us ) know, does the code boot :) |
|
Just a note for future generations: the DIO-mode ROM flashing made it into the master branch and everything works out of the box now. Thanks again, Sprite, for the quick hack-around. |
|
Hey all, I've tried to flash my esp32 but it gets locked into a reboot cycle every 2 minutes. when rebooting the output looks like so: rst:0x7 (TG0WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) W (31) boot: WDT reset info: APP CPU PC=0x40156a50 I (37) boot: ESP-IDF 2018.2.1-76-g02d2e1b4-dirty 2nd stage bootloader I (219) esp_image: segment 3: paddr=0x0004c13c vaddr=0x40080400 size=0x03ed4 ( 16084) load I (514) esp_image: segment 5: paddr=0x00111048 vaddr=0x400842d4 size=0x0f87c ( 63612) load I (540) esp_image: segment 6: paddr=0x001208cc vaddr=0x400c0000 size=0x00000 ( 0) load I (0) cpu_start: App cpu up. any ideas? thank you all. |
|
Shows on arduino serial monitor rst:1x10(RTCWDT_RTC_RESET) , boot:0x1f(SPI_FAST_FLASH_BOOT) |
It's possible for esp_pm_impl_isr_hook(...) to be nested due to the fact that interrupts are nested on the ESP32. To fix this we need to place the acquiring of the lock into a critical section to ensure it does not get nested on the system, otherwise the system will never release the idle lock when this occurs and will not go into lower power states. A sample backtrace encountering this (the code was instrumented to go into a while(1) loop when the condition was hit to get this backtrace) from commit d7a7a68: #0 leave_idle () at esp-idf/components/esp32/pm_esp32.c:444 espressif#1 0x4008143a in esp_pm_impl_isr_hook () at esp-idf/components/esp32/pm_esp32.c:473 espressif#2 0x40082750 in _xt_medint2 () at esp-idf/components/freertos/xtensa_vectors.S:1243 espressif#3 0x4000bff0 in ?? () espressif#4 0x40090bb0 in vTaskExitCritical (mux=0x3ffbd230) at esp-idf/components/freertos/tasks.c:4304 espressif#5 0x40081758 in esp_pm_lock_acquire (handle=0x3ffbd218) at esp-idf/components/esp32/pm_locks.c:126 espressif#6 0x40081399 in leave_idle () at esp-idf/components/esp32/pm_esp32.c:440 espressif#7 0x4008143a in esp_pm_impl_isr_hook () at esp-idf/components/esp32/pm_esp32.c:473 espressif#8 0x400826b8 in _xt_lowint1 () at esp-idf/components/freertos/xtensa_vectors.S:1154 espressif#9 0x400d14b0 in esp_pm_impl_waiti () at esp-idf/components/esp32/pm_esp32.c:483 espressif#10 0x400d2c77 in esp_vApplicationIdleHook () at esp-idf/components/esp32/freertos_hooks.c:63 espressif#11 0x40091008 in prvIdleTask (pvParameters=0x0) at esp-idf/components/freertos/tasks.c:3412 espressif#12 0x40090344 in vPortTaskWrapper (pxCode=0x40090ffc <prvIdleTask>, pvParameters=0x0) at esp-idf/components/freertos/port.c:143 Signed-off-by: Tim Nordell <[email protected]>
ghost
mentioned this issue
* Implement native esp-idf cmake build Move `build.rs` contents to `build_pio.rs` Add feature `native` Add optional dependency `strum` * Remove main wrapper * Fix patches not getting applied, use correct patches * Clarify some `Chip` methods, fix python virtualenv path Use correct target name for `riscv32`. * Fix pio build, tidy code Fix potentially using `:` to split PATH on windows. * Add documentation to README * Change DEFAULT_SDK_DIR to `.espressif` Set min python version to 3.7. Set default build feature to pio. Make `native` feature usable. * Track `sdkconfig` and `sdkconfig_defaults` files.
Hi all,
Testing out the ESP32 moduile with the Template App and the IDF, it gets locked into an infinite-reboot cycle.
Output is like so:
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
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:QIO, clock div:2
load:0x3ffc0000,len:0
load:0xffff0e00,len:-1
1162 mmu set 00010000, pos 00010000
With that last block repeating indefinitely.
That 0xffff0e00 address doesn't smell right, but I have no idea where it's coming from. I have two different modules and both do the same thing. As far as I can tell, the esptool upload verifies correctly.
I'm stumped. Any pointers?
Versions:
esp-idf commit is cef73d9 (with the corresponding esp32/libs)
esp-template-app is 3bbf6ce
toolchain is the binary download (on Sep 5)
The text was updated successfully, but these errors were encountered: