https server based project hits a break point right after start up at cpu_ll_get_cycle_count() (IDFGH-7431) #9008
Comments
github-actions
bot
changed the title
|
DFU is not supported on ESP32 because it requires native USB support and ESP32 doesn't have it. |
|
@dobairoland we talking about ESP32-S2 on ESP32-WROVER II and DFU is not related to the issue. I said we flash and debug with esp-prog. The questions is what to do when a program stalls before app_main() |
dobairoland
changed the title
|
I was mislead by
I've updated the title to attract the right developers for this issue. |
|
Are you getting the same result after flashing with Could you share the full output? Maybe share the coredump as well if possible? Can you try one of the https server examples included in ESP-IDF? Are you getting the same issue? Or can you share a minimal not-working example? Do you own a publicly available board with ESP32-S2? Are you able to run your project on it? |
We flash via Eclipse Plugin and Jtag only, dfu is not of interest and in any involved in this issue.
All sample projects work seamlessly on our custom board. Even the original simple https server sample works on our board. Even if we roll back in our GIT before this ominous incident with the tool chain the project works.
Same on Kaluga, the below output is generated on a Kaluga-1 board
will prepare the coredump, but need to be done using idf.py if I understand correctly. I need some time for this. so far never used idf.py. Finally causing the issue using it. here the output I (324) esp_image: segment 2: paddr=0003ddb0 vaddr=40022000 size=02268h ( 8808) load I (374) esp_image: segment 3: paddr=00040020 vaddr=40080020 size=c6760h (812896) map I (572) esp_image: segment 4: paddr=00106788 vaddr=40024268 size=1aa44h (109124) load I (742) cache: Instruction cache : size 8KB, 4Ways, cache line size 32Byte Setting breakpoint at 0x4014675e and returning... |
|
@ralphde I think I see what's happening here. In The issue is that during You can try to change I'll submit a bugfix for this. |
espressif-bot
added
Resolution: NA
|
@ESP-Marius it worked for me. However, if I understand right it should work as well when I change compiler optimization level back to -Os or -Og and log level to 'info'. But that does not work and has the same effect. So this I don't understand. |
|
Yes, changing to The fix has already been merged to our internal master branch (9177e9f) and it will be backported to v4.4 and v4.3. This topic should be automatically update and closed as soon as this commit is synced to Github (happens when our internal CI passes all tests) As for why nobody else noticed this: my guess is that the combination of of verbose logging (too noisy for most people) and |
@dobairoland
Environment
ESP32-S2 on custom board
IDF version (run
git describe --tagsto find it):// 4.4.1
Build System: Elipse plugin latest
Compiler version (run
xtensa-esp32-elf-gcc --versionto find it):(crosstool-NG esp-2021r2-patch3) 8.4.0
Operating System: win10
(Windows only) environment type: ESP Command Prompt and Plain Command Prompt and PowerShell].
Using an IDE?: Eclipse 2021-09
Power Supply: custom board 3.3V
Problem Description
after performing required steps for creating the DFU as described here []#9003
our https server based project does not run at all any more.
It hits a break point right after start up.
cpu_ll_get_cycle_count()Looking into that, we assume that this may indicate that the ESP goes directly to sleep?
Again, our code was running before without any error or messages. As well this issue appears before any debug or even main() is hit. How to nail this dead end down?
Are we still having version mismatch issues? if so, how can we locate the issue?
We have tried to change a view things in sdkconfig like RTC watchdog etc. but no success
We flash and debug using esp-prog
sdkconfig.zip
The text was updated successfully, but these errors were encountered: