Guru Meditation Error #6
Labels
Resolution: Won't Do
This will not be worked on
Status: Done
Issue is done internally
Status: Opened
Issue is new
Comments
|
FWIW, I did not rebuild the toolchain, just got the binaries from the espressif server. |
|
tasks.c:601 is configASSERT( (xCoreID>=0 && xCoreID<portNUM_PROCESSORS) || (xCoreID==tskNO_AFFINITY) ); it looks like you're trying to start a process on core 2 while FreeRTOS only has one core. Can you check in menuconfig if components->esp32->reserve memory for 2 cores is enabled, and components->freertos->run freertos only on first core is disabled? By the way, 'guru meditation error' is basically a panic or unhandled exception. |
|
Tried removing wifi as @igrr suggested on Twitter, and it works now |
|
Another possible option — we have changed the "no affinity" constant in On Sat, Sep 3, 2016, 13:29 Jeroen Domburg notifications@github.com wrote:
|
|
Oooh, that'll break stuff indeed. |
|
Yeah, @Spritetm's suggestion kinda fixed the issue too, but I get quite a long trace before getting to the app. |
|
Some logs to be removed, yeah. |
|
@AdySan, Guys please :) |
igrr
pushed a commit
that referenced
this issue
Sep 6, 2016
|
master branch should now be updated to avoid the configuration combination that caused this error loop. Thanks for reporting the bug in the first place! |
Closed
Closed
tim-nordell-nimbelink
added a commit
to tim-nordell-nimbelink/esp-idf
that referenced
this issue
Feb 28, 2019
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 <tim.nordell@nimbelink.com>
4 tasks
0xFEEDC0DE64
pushed a commit
to 0xFEEDC0DE64/esp-idf
that referenced
this issue
May 5, 2021
…#3752) This patch fixes update timeouts (error espressif#6) on slow HTTP/HTTPS links.
3 tasks
3 tasks
3 tasks
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just got my Demo board today and followed the steps in this excellent readme.
This part regarding selecting serial port worked well.
make flashdidn't work a couple of times, but then is suddenly worked and finished correctlyAfter that when I reboot the board and look at the serial trace, looks like the chip keep rebooting. Here's the trace
Did I do something wrong?
The text was updated successfully, but these errors were encountered: