Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: Option to omit stopping at app_main (VSC-1438) #1253

Closed
gudvinr opened this issue Jul 19, 2024 · 11 comments · Fixed by #1261
Closed

[Feature Request]: Option to omit stopping at app_main (VSC-1438) #1253

gudvinr opened this issue Jul 19, 2024 · 11 comments · Fixed by #1261
Assignees
Labels
Feature / Enhancement Request Request for Feature/ Enhancement

Comments

@gudvinr
Copy link

gudvinr commented Jul 19, 2024

Is your feature request related to a problem? Please describe.

I never break on app_main entry unless I want to specifically debug startup process from get-go.

You can't simply set breakpoint whenever you want and then build, flash and wait for breakpoint to trigger.
You need to wait for app_main triggering first and then continue.

Describe the solution you'd like

Add an option to suppress breaking on app_main.

esp_debug_backend already has start_func parameter in exec_run, which can be set to empty string to skip adding breakpoint.

Describe alternatives you've considered

Additional context

@gudvinr gudvinr added the Feature / Enhancement Request Request for Feature/ Enhancement label Jul 19, 2024
@github-actions github-actions bot changed the title [Feature Request]: Option to omit stopping at app_main [Feature Request]: Option to omit stopping at app_main (VSC-1438) Jul 19, 2024
@brianignacio5
Copy link
Collaborator

So by default the new debug adapter has these init commands (not written in launch.json itself but in extension code):

"initCommands": [
        "set remote hardware-watchpoint-limit {IDF_TARGET_CPU_WATCHPOINT_NUM}",
        "mon reset halt",
        "maintenance flush register-cache",
        "thb app_main"
      ],

You can open the launch.json and modify initCommands to remove line that sets breakpoint in app_main thb app_main.

"initCommands": [
        "set remote hardware-watchpoint-limit {IDF_TARGET_CPU_WATCHPOINT_NUM}",
        "mon reset halt",
        "maintenance flush register-cache"
      ],

@gudvinr
Copy link
Author

gudvinr commented Jul 23, 2024

Should be good enough as a workaround but suboptimal as the solution.

Startup commands can change after extension update and one must inspect source code after every release to match custom commands

On the other hand, cortex debug has runToEntryPoint

@brianignacio5
Copy link
Collaborator

How about we add the c after the thb app_main as done in here ?

I'm trying to keep default behavior as default as possible. Although is possible to add something like runToEntryPoint a regular will prefer just to set a breakpoint in the debugger UI itself.

@gudvinr
Copy link
Author

gudvinr commented Jul 25, 2024

How about we add the c after the thb app_main as done in here ?

I don't have a solid opinion on that. It depends on what most users need (or what you think would be good default).

If it'd be the default with no options added I am fine with it since I don't use break on entry point that often and manual breakpoint is what I'd do anyway. This is usual behaviour for most debugging in non-embedded space so it doesn't seem like a big deal.

Another option is to make config parameter that controls adding c after thb app_main and I am fine with that either. OR make an option to append commands to initCommands. Then one could add c.

Another option is to make config parameter controlling adding thb app_main and then not breaking on entrypoint would be default and parameter would control adding thb app_main (or not add c) to initCommands.
Similarly, default initCommands may omit thb app_main and if user needs that, option that appends commands can be used to extend initCommands.

All in all, any of these will be fine as long as it is documented.

@brianignacio5
Copy link
Collaborator

I've made these changes in #1261

You can try these changes using this vsix installer to see if it works for you. Same for the trailing comma issue here.

@gudvinr
Copy link
Author

gudvinr commented Jul 25, 2024

You can try these changes using this vsix installer to see if it works for you.

Doesn't seem to be working. App still stopping on app_main. And I don't have custom initCommands.

Extension is updated though, because I don't see an issue with trailing comma anymore.

@gudvinr
Copy link
Author

gudvinr commented Jul 26, 2024

I do see that it's trying to continue though, so command itself gets executed:

JTAG tap: esp32s3.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
JTAG tap: esp32s3.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
[esp32s3.cpu0] requesting target halt and executing a soft reset
[esp32s3.cpu0] Debug controller was reset.
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x500000EF, debug_reason=00000000
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
[esp32s3.cpu1] requesting target halt and executing a soft reset
[esp32s3.cpu0] Core was reset.
[esp32s3.cpu0] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Debug controller was reset.
[esp32s3.cpu1] Core was reset.
[esp32s3.cpu1] Target halted, PC=0x40000400, debug_reason=00000000
[esp32s3.cpu1] Reset cause (3) - (Software core reset)
[esp32s3.cpu0] Reset cause (3) - (Software core reset)
maintenance flush register-cache
Register cache flushed.
thb app_main
Hardware assisted breakpoint 1 at 0x420114a5: file main.cpp, line 24.
GDB unhandled notify: breakpoint-created: {"bkpt":{"number":"1","type":"hw breakpoint","disp":"del","enabled":"y","addr":"0x420114a5","func":"app_main()","file":"main.cpp","fullname":"main.cpp","line":"24","thread-groups":["i1"],"times":"0","original-location":"app_main"}}
c
Continuing.
[esp32s3.cpu0] Target halted, PC=0x420114A5, debug_reason=00000001
Set GDB target to 'esp32s3.cpu0'
[esp32s3.cpu1] Target halted, PC=0x40381648, debug_reason=00000000
[New Thread 1070304356]
[Remote target exited]
[New Thread 1070308764]
[New Thread 1070306560]
[New Thread 1070290364]
[New Thread 1070294808]
[New Thread 1070288480]
[Switching to Thread 1070304356]

Thread 2 "main" hit Temporary breakpoint 1, app_main () at main.cpp:24
24		ESP_ERROR_CHECK(nvs_flash_init());

There is some warning though but I don't know if it has any relevance:

GDB unhandled notify: breakpoint-created: {"bkpt":{"number":"1","type":"hw breakpoint","disp":"del","enabled":"y","addr":"0x420114a5","func":"app_main()","file":"main.cpp","fullname":"main.cpp","line":"24","thread-groups":["i1"],"times":"0","original-location":"app_main"}}

@brianignacio5
Copy link
Collaborator

brianignacio5 commented Aug 8, 2024

@gudvinr Can you try this vsix installer ?

Setting "initialBreakpoint" : "" should ignore the initial breakpoint.

@brianignacio5 brianignacio5 self-assigned this Aug 8, 2024
@gudvinr
Copy link
Author

gudvinr commented Aug 8, 2024

@gudvinr Can you try this vsix installer ?

Seems to be working. According to logs, maintenance flush register-cache is the latest command executed.

@gudvinr
Copy link
Author

gudvinr commented Aug 9, 2024

Thanks, much appreciated

@brianignacio5
Copy link
Collaborator

If you find the extension useful. Please leave us a review in the Visual Studio Code Marketplace

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature / Enhancement Request Request for Feature/ Enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants