You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setup Debugging is a pain. Since probe-rs starts to get in good shape with respect to debugging esp-idf it would be nice if we provide support for it in esp-idf-template.
Solution
Probe-rs itself strictly doesn't need VSCode, but it provides a really nice VSCode extension. We should provide working auto-generated launch.json configs for this. Since not everybody is using VSCode i think it maybe is best to introduce it as a step in the advanced setup? If we don't want to many advanced configs we could merge it either with the wokwi step or make it standalone.
other open questions
should we provide svd Files ( for debugging Peripherals) ?
this should probably not replace the runner from espflash to probe-rs since probe-rs only use rtt and doesn't care about the serial output, but maybe provide a outcommented runner in the .cargo/config for convenience?
should we make the generation only availabe for targets that have a built in jtag available at first?
Notes
esp-idf has still some quirks - By default on riscv targets if a debugger is attached, the system will not be able to set a breakpoint from code by itself. It uses custom semihosting commands to tell the debugger to set and unset breakpoints on behalf of the system. ( work is currently done supporting more semihosting stuff in probe-rs). This is if the code itself wants to set a breakpoint, not when the user sets one in there editor.
This behavior crates the following problem. By default the IWDT(Interrupt Watchdog Timer) is always enabled and cannot be simply halted. On connection of the debugger and on a user set breakpoint the system will halt, but the IWDT will still trigger after half a second. The IWDT works in staged manner, e.g after a first timeout it will raises a special panic, that would set a breakpoint from code. The catch22 is that because we are in a debugger session, and the semihosting call to let the debugger set the breakpoint does currently not get answered correctly from the probe-rs, the IWDT will go into the second stage after a additional timeout and hard-reset the esp. (Making debugging impossible)
For now a user needs to build esp-idf with CONFIG_ESP_INT_WDT=n set in the sdkconfig.default file. This is not ideal since a real application should always have this enabled, but i hope in the future we can make this always work.
The text was updated successfully, but these errors were encountered:
Motivations
Setup Debugging is a pain. Since
probe-rs
starts to get in good shape with respect to debugging esp-idf it would be nice if we provide support for it in esp-idf-template.Solution
Probe-rs itself strictly doesn't need VSCode, but it provides a really nice VSCode extension. We should provide working auto-generated launch.json configs for this. Since not everybody is using VSCode i think it maybe is best to introduce it as a step in the advanced setup? If we don't want to many advanced configs we could merge it either with the wokwi step or make it standalone.
other open questions
espflash
toprobe-rs
sinceprobe-rs
only use rtt and doesn't care about the serial output, but maybe provide a outcommented runner in the .cargo/config for convenience?Notes
esp-idf has still some quirks - By default on riscv targets if a debugger is attached, the system will not be able to set a breakpoint from code by itself. It uses custom semihosting commands to tell the debugger to set and unset breakpoints on behalf of the system. ( work is currently done supporting more semihosting stuff in probe-rs). This is if the code itself wants to set a breakpoint, not when the user sets one in there editor.
This behavior crates the following problem. By default the IWDT(Interrupt Watchdog Timer) is always enabled and cannot be simply halted. On connection of the debugger and on a user set breakpoint the system will halt, but the IWDT will still trigger after half a second. The IWDT works in staged manner, e.g after a first timeout it will raises a special panic, that would set a breakpoint from code. The catch22 is that because we are in a debugger session, and the semihosting call to let the debugger set the breakpoint does currently not get answered correctly from the probe-rs, the IWDT will go into the second stage after a additional timeout and hard-reset the esp. (Making debugging impossible)
For now a user needs to build esp-idf with
CONFIG_ESP_INT_WDT=n
set in the sdkconfig.default file. This is not ideal since a real application should always have this enabled, but i hope in the future we can make this always work.The text was updated successfully, but these errors were encountered: