- This topic has 6 replies, 2 voices, and was last updated 2 years, 5 months ago by
.
-
Posts
-
hi everyone,
I am evaluating the visualgdb toolchain in trial mode and right now i am stumped on the upload and debugger attaching procedure,
JTAG connector between board and Esp-Prog is verified to work ok, since from eclipse esp-idf i am able to upload and attach to breakpoint. I followed mostly defaults for the setup in visualgdb, since i could not find the exact screens for specific ESP32-WROOM-32.
I also tried the workaround for resetting the target with the software breakpoint function, and i am using the following function:static int SysprogsDebuggerIsAttached; void __attribute__((noinline)) WaitForSysprogsDebugger() { asm("break 1, 1"); while (!SysprogsDebuggerIsAttached) { } }this function is sitting right below app_main()
still I cannot get the debugger to attach or halt or anything that indicates that i am actively debugging
i hope the attached logs could provide some insight to someone help me out please
have a nice day
Hi,
Based on the log, it looks like the connection has been established.
Could you please describe a bit more what is happening: does Visual Studio show that a breakpoint has been set (i.e. shows it as a solid circle)? What happens if you use the Debug->Break All command to pause the target?
Please also try attaching a gdb log – it will show what is going on.
i really dont understand this process,
first, early debug session (that i did not correctly capture with the logs) succesfully uploaded the firmware image to the target, and the blink project made my gpio pin blink correctly. Doing break all gave me the following error:
Frame not in module
The current stack frame was not found in a loaded module. Source cannot be shown for this location.I instrumented that gdb log after that and since then i cannot succesfully get the blink project to run. The upload itself seems fine but when i reset the target, it goes to an undefined area in the chip, i guess. I attached that specific log, maybe there is already indication what i do wrong?
FYI, i upload via jtag as well, for that i have to boot into the programmer mode (with the BOOT/RESET combo).
Hi,
According to the gdb log, it actually manages to stop in main() before stopping in the unknown location:
[ 13421 ms] *stopped,reason="breakpoint-hit",disp="keep",bkptno="2",frame={addr="0x400d4bab",func="app_main",args=[],file="../../../main/blink_example_main.c",fullname="C:\\Users\\Jens\\Documents\\ESP32\\Solutions\\EmbeddedSolution1\\EmbeddedProject1\\main\\blink_example_main.c",line="74",arch="xtensa"},thread-id="1",stopped-threads="all"Please try removing the WaitForSysprogsDebugger() function and using F10 instead of F5 to start the debug session. It will automatically stop the program at the beginning of app_main(), so you will be able to step through it and see which parts of the program work.
thank you, with the above I was able to launch debug session and halting on breakpoint. It throws an error message before i can run but i am able to reach the entry point and start/run the program,
i attached a screenshot of the error message that pops up before I start running. Could you perhaps elaborate on it? Could it be an indication of things set up wrong?
If i have to guess, it looks like something expects the stack to grow down in the address range ? but detects that in this case it is not? I dont have much familiarity with the chip yet at that level of detail and I try to leave the datasheet closed as long as possible =D
have a nice day, so far I like the tool and hope I can continue with it.
This looks like you have configured some extra settings in the project to incompatible values.
Please try reproducing the problem on a project created from scratch. If the problem persists, please let us know the steps to reproduce it per our problem reporting guidelines. If the newly created project works, please try comparing its settings against the current project settings and make sure they match.
- You must be logged in to reply to this topic.