usb_jtag_serial_read_bytes not returning for IDF >= 5.1.2

[maierkomor]

Hi,
sind IDF versions 5.1.2, I have issues with usb_jtag_serial_read_bytes not returning from its call although input is available. This is not an issue with IDF 5.1.1 and before.
When I attach the debugger, and try to analyze the situation, the function returns normally and delivers the data as expected.

Any ideas, why this might be the case? To me it looks like some kind of interrupt configuration issue, but as I cannot reproduce it in the debugger, I am a bit lost. I tried IDF 5.1.2, 5.1.3, 5.1.4, 5.2, 5.2.1...

Regards,
Thomas

[ESP_Sprite]

That is odd, nothing changed in the USB-serial-JTAG driver between 5.1.1 and 5.1.2. Can you post a minimum example that shows this behaviour?

[maierkomor]

Reproducing a minimal source code is hard, because of the structure of the overall project. I tried to remove everything unrelated and was able to produce of the stack trace of the blocked jtag read.

Here, it is:

#0 0x40386350 in vPortClearInterruptMaskFromISR (prev_int_level=1)
at /work/atrium/idf/idf-esp32-5.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:520
#1 0x403863a6 in vPortExitCritical ()
at /work/atrium/idf/idf-esp32-5.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:620
#2 0x40384a4e in prvReceiveGeneric (pxRingbuffer=0x3fc9a0c8, pvItem1=pvItem1@entry=0x3fc9f39c, pvItem2=pvItem2@entry=0x0,
xItemSize1=xItemSize1@entry=0x3fc9f3cc, xItemSize2=xItemSize2@entry=0x0, xMaxSize=1, xTicksToWait=<optimized out>)
at /work/atrium/idf/idf-esp32-5.2/components/esp_ringbuf/ringbuf.c:876
#3 0x40385058 in xRingbufferReceiveUpTo (xRingbuffer=<optimized out>, pxItemSize=pxItemSize@entry=0x3fc9f3cc,
xTicksToWait=<optimized out>, xMaxSize=<optimized out>) at /work/atrium/idf/idf-esp32-5.2/components/esp_ringbuf/ringbuf.c:1178
#4 0x420674e6 in usb_serial_jtag_read_bytes (buf=0x3fc9f41f, length=<optimized out>, ticks_to_wait=<optimized out>)
at /work/atrium/idf/idf-esp32-5.2/components/driver/usb_serial_jtag/usb_serial_jtag.c:196
#5 0x4201e826 in JtagTerminal::read (this=<optimized out>, block=true, s=1, buf=0x3fc9f41f "")
at /work/atrium/components/term/jtag_terminal.cpp:52
#6 JtagTerminal::read (this=<optimized out>, buf=0x3fc9f41f "", s=1, block=true)
at /work/atrium/components/term/jtag_terminal.cpp:46
#7 0x4201e202 in Terminal::readInput (this=this@entry=0x3fc9e52c, buf=buf@entry=0x3fc9f460 '\245' <repeats 76 times>,
l=l@entry=127, echo=echo@entry=true) at /work/atrium/components/term/terminal.cpp:67
#8 0x4200d986 in shell (term=..., prompt=prompt@entry=true) at /work/atrium/main/shell.cpp:2876
#9 0x42009288 in console_task (con=0x3fc9e52c, con@entry=<error reading variable: value has been optimized out>)
at /work/atrium/main/console.cpp:52
#10 0x40386236 in vPortTaskWrapper (pxCode=<optimized out>, pvParameters=<optimized out>)
at /work/atrium/idf/idf-esp32-5.2/components/freertos/FreeRTOS-Kernel/portable/riscv/port.c:255

Any idea what might be causing the hang here?

[maierkomor]

I have reduced the startup sequence to directly start just the jtag terminal. I.e. there is no code left, but the thread that is hanging on the usb_jtag_serial_read_bytes.

The idle task is waiting in esp_cpu_wait_for_intr. The only other threads running at that points are the one created by the IDF before entering app_main(). I.e. "Tmr Svc" and "esp_timer"

[maierkomor]

This code reproduces the problem for me.

Code: [Select all] [Expand/Collapse]

1. #include <stdio.h>
2. #include <inttypes.h>
3. #include "sdkconfig.h"
4. #include "freertos/FreeRTOS.h"
5. #include "freertos/task.h"
6. #include "esp_chip_info.h"
7. #include "esp_flash.h"
8. #include "esp_system.h"
9. #include <driver/usb_serial_jtag.h>
10.  
11. void app_main(void)
12. {
13.     printf("Hello world!\n");
14.     usb_serial_jtag_driver_config_t cfg = USB_SERIAL_JTAG_DRIVER_CONFIG_DEFAULT();
15.     cfg.rx_buffer_size=256;
16.     cfg.tx_buffer_size=256;
17.     usb_serial_jtag_driver_install(&cfg);
18.  
19.     while (1) {
20.             uint8_t buf[8];
21.             int n = usb_serial_jtag_read_bytes(buf,sizeof(buf),0);
22.             if (n > 0) {
23.                     usb_serial_jtag_write_bytes(buf,n,portMAX_DELAY);
24.                     continue;
25.             }
26.             n = usb_serial_jtag_read_bytes(buf,1,portMAX_DELAY);
27.             if (n <= 0)
28.                     continue;
29.             int x = usb_serial_jtag_read_bytes(buf+1,sizeof(buf)-1,portMAX_DELAY);
30.             usb_serial_jtag_write_bytes(buf,n+x,portMAX_DELAY);
31.     }
32. }

GeSHi © Codebox Plus Extension

[maierkomor]

Doing some more experiments, I come to the impression that the read does actually work as expected, but the write seems to be masked out by the IO-MUX. Could that be the case? How can I make sure that the IO-MUX is routing the D+/D- correctly to the pins and not being overridden as a GPIO?

Are there any hints or pointers available to relevant documentation?

[ESP_Sprite]

Thanks, having an example and a known good/bad ESP-IDF makes it very simple to 'git bisect' to the commit where the issue is. Seems something went wrong around commit 518212a8f664beb475ebbbb9882637dbdce68348, I'll look into it.

Doing some more experiments, I come to the impression that the read does actually work as expected, but the write seems to be masked out by the IO-MUX.

Fyi, that's not really a thing that happens over USB... USB is a pretty complicated protocol, and if D+ or D- gets disconnected somehow, you'll likely lose the device as it doesn't respond to the host anymore.

[ESP_Sprite]

Well, what I can tell you is that it works again on master... seems that commit b8e8042c4e48c5ac00aeb17fa621d32d1e34a1be fixes it. You may be able to cherry-pick that commit.

[maierkomor]

I just tried applying that changeset to 5.1.4. It does not apply cleanly (1 line that gets deleted is not there).
Unfortunately, this change does not fix 5.1.4, i.e. after building with this patch applied, does not restore correct jtag-usb communication.

[ESP_Sprite]

Can you check if the master branch still reproduces this for you?