OpenOCD/JTAG error: Target is already running an algorithm (IDFGH-8612) (OCD-872) #306
Open
3 tasks done
Assignees
Labels
Comments
|
Body was too long... sdkconfig |
github-actions
bot
changed the title
vdm97
changed the title
|
there is a good debugging doc in the esp-idf vscode extension repo, if you haven't found it. |
|
Hi there, I already posted at the ESP32.com forum: |
Hi, the specific error code is different (yours is
I investigated the error with more detailed debug output, but i lack the neccessary JTAG/OpenOCD knowledge to find a solution. I added the debug output of ESP-IDFv5.0-beta1 for someone who has the neccessary knowledge. ESP-IDFv5.0-beta1 OpenOCD logPS: Should i post this error in the ESP32-OpenOCD repo? |
|
here is the doc I was referring to: https://github.com/espressif/vscode-esp-idf-extension/blob/master/docs/DEBUGGING.md |
Thank you for the link but i do not get how this should help me. The error is not present when Bluetooth is deactivated and only appears when i activate Bluetooth so i do not think that it is a VSCode ESP IDF extension / OpenOCD misconficuration. I could be wrong of course.. |
|
I have some new information regarding this issue. While adding the BLE functionality i noticed, that my heap gets really full. Therefore i spent some time freeing up space. Yesterday i updated to ESP-IDF v4.4.3 and noticed that my flashing problem does not occur anymore. After some testing i found out that it was not the new version of ESP-IDF that fixed the problem but instead freeing up the heap. I attached the output of Heap summary working caseHeap summary broken caseImage size working caseImage size broken caseIf find the fix really strange and think that freeing up the heap is not the real fix but i cannot think of any other change i did to the code which might cause the issue/fix. Therefore i am not sure if i should close this issue. |
|
Yesterday I encountered a similar JTAG problem. Does anyone else think it might be related to the I'm not sure I've ever encountered a low memory issue causing JTAG programming problems. Is there a device RAM overhead for JTAG programming and/or single-step debugging? @vdm97 I'd be interested in seeing your |
|
Hi @gojimmypi, my sdkconfig is posted above:
PS: I do not use the |
|
Today i encountered this error again. After updating from IDF version 4.4.3 to version 5.0.2 my IRAM usage was at 92.7 % and i could not flash my ESP32-WROOM-32 a second time anymore. So i started to search for a solution and found this issue but updating OpenOCD to the newest release did not help. Therefore i removed the last configurable piece of code from the IRAM (CONFIG_LWIP_IRAM_OPTIMIZATION) which reduced the IRAM usage to 82.2 %. After a manual flash via serial flashing i could flash again with the ESP-IDF VS Code Extension like before. So unfortunately the error is still present... |
|
Thanks for your investigations. You mentioned the heap size... could it possibly be related to written flash size? (I'm a total beginner, so I'm just brainstorming here.) I'm seeing similar -- my procedure is to switch to a smaller project and do a non-debug upload. Then I can go back to the "large" project and do a debug upload and it works, but only one time. Then the board is "broken" for debugging until I repeat the procedure. I posted at the PIO forum with some more details: https://community.platformio.org/t/interesting-results-re-chronic-esp-prog-problems/37168 Relevant quote:
It's interesting to me that your flash usage is right around where mine is... I've been incrementally building this project, and it just started to fail, so if in fact there is a firm threshold of image size that triggers the issue, I would expect it to be near the size I'm currently failing at (1044480.) |
|
Sorry, I just saw this long-time-opened issue. OpenOCD uses the IRAM memory As I understand, when your application IRAM usage is high, you can not update your application from the JTAG. Correct? I can try to create a test app, to reproduce the issue by allocating a high chunk of memory from the heap. Or maybe someone can do it by simulating the application memory usage? Also, are any other settings needed to see the failure? I am sorry to hear that this issue is called a 'chronic' in the community. I will do my best to find a solution. |
|
Thanks! I have been working this morning to narrow things down. Unfortunately I am a beginner and barely know C or microcontrollers (e.g. I barely understand what IRAM even is) but I will help if I can! Here is what I found today (doing this on an ESP32-DevKitC-VIE which uses WROVER): Suspecting that the issue was written flash size, I made a program that #include's "bigfile.h" where bigfile is like this: (they are ints and I mistakenly assigned bytes, but I assume that's irrelevant) And main.cpp was: ...even though flash was 99.5% used, this debugged fine. So instead I used a python script to generate ../include/bigfile.cpp which is like this: And main is like this: I'm a clueless beginner so I'm obviously just trying anything I can to prevent the code from being optimized away. No idea if any of this is smart. If I generate bigfile.cpp with 124 functions (and main calls func123(0)) then it works: I can debug multiple times in a row. If I generate bigfile.cpp with 125 functions (and main calls func124(0)) then I can debug the first time but it doesn't debug properly: e.g. it stops at setup() and I hit F5 and it stops at some random other place for no apparent reason. Then when I stop debugging and try to F5 again, it does not work, etc. In other words, it's the same pattern as described: I have to flash in non-debug mode, and I must do so with a smaller-sized program (e.g. regenerate bigfile.cpp with 124 or less functions). Then it will work again. platformio.ini of test projectApologies if everything in this comment is a waste of time; I just wanted to share in case it is useful. Maybe the way I am nesting function calls in the test code is bound to cause problems and this is a different issue. At any rate, if there is anything else I can do to assist let me know! Here are debug console outputs: goodflash_at_124 is the one that worked repeatedly; goodflash_but_bad_session_at_125.txt is where it seemed to flash OK but debugging was unpredictable/broken. badflash_at_125 is the subsequent attempt to flash which just hangs. The specific errors and pattern of failure are a little different from my real project, but I guess that would be expected if this is a case of the process overwriting openocd memory accidentally or something. goodflash_at_124.txtgoodflash_but_bad_session_at_125.txtbadflash_at_125.txt |
github-actions
bot
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
v4.4.2, v5.0-beta1, v5.0.2
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
What is the expected behavior?
A successful flash via OpenOCD/JTAG.
What is the actual behavior?
My company uses a custom board where the ESP32-WROOM-32 with 16MB flash (ESP32) is used as a WiFi chip. For that purpose it works very well, so thank you very much for providing the chip and the good tools! We use the VS Code ESP extension in conjunction with the ESP-Prog Board (JTAG) which works (most of the time) quite good. Furthermore the ESP32 is connected to a STM32 and UART is used for communication. The STM32 can also be used as a last hope to flash the ESP32.
Now about the problem. We wanted to expand the usage of the ESP32 by adding Bluetooth Low Energy (BLE) functionality. For that we activated Bluetooth in the menuconfig and selected the NimBLE stack. This did not work with the error described below. After some searching we found this ticket with a similar error in the OpenOCD log and updated our ESP-IDF from v4.4.1 to v4.4.2 and then to v5.0-beta1 (After realising that the fix is not part of v4.4.2.). After this BLE worked fine on its own and with WiFi coexistence but the WiFi stopped working with timeout issues (SPIFFS could not be served). To fix the issue we tried different task priorities for WiFi and BLE and varying BLE window and interval settings but without success. In the end we opened the menuconfig and changed the BLE stack to Bluedroid. With this stack BLE and WiFi works in coexistence but our initial error appeared again. The OpenOCD log where the error appears is attached below.
We do not know what the real cause of the error is but it appears on ESP-IDF v4.4.1 and v4.4.2 when we activate Bluetooth and select the NimBLE or Bluedroid stack. After we switched to ESP-IDF v5.0-beta1 the error only appears when we select the Bluedroid stack but does not appear when we select the NimBLE stack (We are ignoring the NimBLE/WiFi coexistence error/misconfiguration? here.). To fit a BLE stack on the ESP we had to deactivate all three WiFi IRAM optimizations, so maybe this plays a role in the error. Furthermore the IRAM and DRAM of the ESP32 is quite full so maybe this plays also a role.
Interestingly the ESP32 can always be flashed with the same binary (BLE enabled with Bluedroid stack) when the STM32 is used for serial flashing and the code is working fine if we look at the monitor and connect via WiFi/BLE but the same binary can only be be flashed the first time when OpenOCD/JTAG is used for flashing. On the second flashing the error in OpenOCD/JTAG appears, so BLE/Bluedroid code has to be present on the ESP32 for the error to appear.
All help is appreciated and we are happy to provide more information if needed.
Steps to reproduce.
I cannot provide our closed source firmware of the ESP32 and building an example is not easy because we have a lot of parts and i am not really sure where the error is coming from. I will take the time to do that if it will not be possible to get help otherwise.
Build or installation Logs.
Image size
OpenOCD (The VS Code extension is responsible for the strange formatting...)
More Information.
No response
The text was updated successfully, but these errors were encountered: