ESP32-S3 JTAG Bridge SRST Problem

[skiddd]

Greetings Esteemed Colleagues,

I have a problem using the USB-JTAG Bridge feature of the ESP32-S3.

I want to program to another MCU via the ESP32-S3's USB JTAG Bridge feature.

I used the code snippet suggested by ESP_Sprite in this thread: https://esp32.com/viewtopic.php?t=25670

Code: Select all

WRITE_PERI_REG(USB_SERIAL_JTAG_CONF0_REG, READ_PERI_REG(USB_SERIAL_JTAG_CONF0_REG)|USB_SERIAL_JTAG_USB_JTAG_BRIDGE_EN);

    esp_rom_gpio_connect_out_signal(GPIO_NUM_43, 85, false, false); //tck
    esp_rom_gpio_connect_out_signal(GPIO_NUM_44, 86, false, false); //tms
    esp_rom_gpio_connect_out_signal(GPIO_NUM_45, false, false); //tdi
    esp_rom_gpio_connect_out_signal(GPIO_NUM_39, 251, false, false); //trst, wire to reset or EN of target
    esp_rom_gpio_connect_in_signal(GPIO_NUM_46, false); //tdo

I can confirm after checking with Logic Analyzer that TCK, TMS and TDI are in fact "bridged" to GPIO 43, 44 and 45 respectively. However, whenever I try to send an SRST HIGH (command nibble 9h via the JTAG command processor), it also resets the ESP32-S3 itself.

Upon checking the TRM 1.2, I found:

USB_SERIAL_JTAG_USB_JTAG_BRIDGE_EN Set this bit usb_jtag, the connection between
usb_jtag and internal JTAG is disconnected, and MTMS, MTDI, MTCK are output through GPIO
Matrix, MTDO is input through GPIO Matrix. (R/W)

Again from TRM 1.2, I found:

... TCK, TMS, TDI and TDO are connected directly to the JTAG debugging logic of the
Xtensa CPUs. SRST is connected to the reset logic of the digital circuitry in the SoC and a high level on this line
will cause a digital system reset. Note that the USB Serial/JTAG Controller itself is not affected by SRST.

Since this "bridge" feature is enabled by a code snippet inside the user APP, if the ESP32-S3 is restarted it will disable this "bridge" feature.

If this is the case, how can I use the JTAG bridge feature without resetting the ESP32-S3 each time I issue a reset cycle on the SRST line?

Furthermore, from TRM 1.2 I came across USB­to­JTAG Control Requests:

VEND_JTAG_SETIO can bypass the JTAG command processor to set the internal TDI, TDO, TMS and
SRST lines to given values. These values are encoded in the wValue field in the format of 11’b0, srst, trst,
tck, tms, tdi.

It would appear that SRST and usb_jtag_trst can be controlled separately. What is the difference between srst and trst here when setting usb_jtag_trst high already effectively resets the ESP32-S3?


Best Regards,

[ESP_Sprite]

Can confirm that SRST still resets the main CPU. I've talked to the digital team and this seems to be an oversight in all of our chips having the bridge mode until now, unfortunately.

SRST and TRST are two separate signals. SRST resets the target system, as you saw. TRST is a signal in the JTAG spec that would reset the JTAG TAP, but since it's generally unused as it's not needed for any ESP as you can also do that using the other signals, within the ESP32-S3 it is not used or connected. It's implemented and given a GPIO pin in bridge mode because other devices may need it, but to be honest I cannot think of one that does.

I'll talk to the tools team; potentially we can use that fact to work around this issue in OpenOCD. TRST does nothing in the chip itself but is available as a GPIO, and as such we could repurpose it as a SRST pin if bridge mode is enabled.

[skiddd]

Thank you for confirming that ESP_Sprite.

As a work around, I am now using the "bridged" TRST (usb_jtag_trst) to reset the external MCU instead. I just issue USB Control request VEND_JTAG_SETIO and use bit 3 of wValue to toggle it high or low. Everything is working fine now.

Best Regards,

[ESP_Sprite]

Good to hear you got it working, and thanks for pointing this out: we weren't aware of that SRST behaviour before.