[Bug Report]: "ESP-IDF Build, Flash and Monitor" will not flash through JTag (VSC-647)

I’m not certain if this is a bug or something I’m missing, but it smells like a bug…

If I build a project and then use the “ESP-IDF Flash device” button (or the “ESP-IDF: Flash (with JTag)” command), all is well and I get a JTag flash through a ESP-PROG to a ESP32 device. However, if I use the “ESP-IDF Build, Flash and Monitor” button (or command), the flash process attempts to do a UART flash through a non-existent COM1 port.

This is on Windows 10 with the current ESP-IDF and with openocd-esp32-win32-0.10.0-esp32-20210401.

The settings.json in the project directory was set by “ESP-IDF: Select OpenOCD Board Configuration” and contains:

{
"C_Cpp.intelliSenseEngine": "Tag Parser",
"idf.adapterTargetName": "esp32",
"idf.openOcdConfigs": [
	"interface/ftdi/esp32_devkitj_v1.cfg",
	"target/esp32.cfg"
],
"idf.flashType": "JTAG"
}

My assumption is that there shouldn’t be another setting to tell it “no, really, I want JTag flashing”, but perhaps I’m missing something. 😄

[meltdown03]

Yeah I did. I have it set in the main settings.json and the project. I still get a failed+to+match+version error unless it’s set in the main settings.json. Maybe there is too much going on and I should start a new issue. I also can’t build the extension from source anymore either.

On Wed, May 5, 2021, 3:08 PM Chris Pearson @.***> wrote:

@meltdown03 https://github.com/meltdown03 , your problem doesn’t seem to be related to this bug report.

That said, and at the risk of going off-topic but wanting to help… Did you change your idf.customExtraPaths and your idf.customExtraVars to match the new OpenOCD 20201202 location?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/vscode-esp-idf-extension/issues/392#issuecomment-832973155, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPBQCEIQQAHCDOP7XVZVTLTMGQSFANCNFSM432SLZXA .

[pearson]

The JTAG flashing feature was added later that build, flash and monitor.

Aha! That would make sense.

I do get the feeling that JTAG flashing is not all that common, and that perhaps most things to do with JTAG could use a bit of love. This is off-topic, but a good example seems to be the logging to host via JTAG feature and application tracing. While it works, there doesn’t seem to be any tools to monitor that logging in real time. It appears to require a clumsy combination of a telnet connection to OpenOCD in order to give the command to start a trace file, followed by using a python script to dump the log text from the trace file.

I like the idea of the lower overhead logging that this offers, so clicking build, flash and monitor and having it flash with JTAG, followed by monitoring by JTAG, would be my ideal. Perhaps, sometime down the road, working on a real-time JTAG monitor might be my contribution to the project… 😃