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.

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...

Another hint for tracking the issue down. It might be the case that a mount attempt failed before calling the f_getfree. So it might be a case, of incomplete cleanup of the relevant data-structures after a failed mount attempt.

f_getfree calls mount_volume, which calls get_ldnumber, which crashes in lock_volume, if no volume is mounted. The crash is due to an assertion failure of an uninitialized Mutex in xQueueSemaphoreTake, called by ff_mutex_take. Both Mutex[0] and FatFs[0] seem to have an invalid pointer at that time.

This code reproduces the problem for me. #include <stdio.h> #include <inttypes.h> #include "sdkconfig.h" #include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "esp_chip_info.h" #include "esp_flash.h" #include "esp_system.h" #include <driver/usb_serial_jtag.h> void app_main(void) { print...

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 ...

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/...

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 exp...

The frame buffer and transfer buffer are allocated once at the beginning and used over the whole execution time. The same code runs finde in multi-core mode on an ESP32 with IDF v4.4.4. Looking at what is written to the screen, it seems like there is some other issue. For me it looks like a complete...

Concerning the maximum transfer size, the message was not regarding max_transfer_sz but shows up as follows, when DMA channel is set to something else than SPI_DMA_CH_AUTO: E (3157) spi_master: check_trans_valid(775): txdata transfer > host maximum The transfer size in that case is 4096. Same proble...