Accessing normal UART interrupts with USB-serial-JTAG with

[second.string]

I would like to use the USB-serial-JTAG component of the S3 modules to process data coming in from the serial port, but not standard ASCII text UART. It is a protocol where I need to align on the packets to make sure i'm receiving the full set of data. The suggested way to receive data with this component from the documentation is to call `usb_serial_jtag_read_bytes` with the # of bytes expected. This does not work for my use-case because:
* if I call it with the full byte count of the expected packet, if my device boots in the middle of a streaming packet then it will always be receiving incorrect data (i.e. the second half of one packet and the first half of the following packet)
* if I call it with a byte count of 1, I have no way to distinguish when one packet starts and one ends (this protocol does not mandate a minimum time between packets that I could use a timer to measure)

The standard way of parsing this protocol is to wait for the BREAK condition at the start of the packet, then receive the correct amount of bytes. The esp32 UART peripheral has a break(1) interrupt that works properly. However, I cannot seem to find a way to enable and handle regular UART interrupts when using the USB-serial-JTAG component. In the component source code, I can see a call to `esp_intr_alloc` and the ISR (2), but it's handling a set of interrupts specific to the component.

Because this is a separate peripheral (USB-based) than a standard UART, is it not possible to process standard UART interrupts since it's coming over USB and not a serial connection?

(1) https://github.com/espressif/esp-idf/bl ... t_ll.h#L47
(2) https://github.com/espressif/esp-idf/bl ... jtag.c#L58

[MicroController]

So your question is actually if/how a BREAK can be detected when using the USB-JTAG serial?

[ESP_Sprite]

It cannot. USB-CDC-ACM uses a SEND_BREAK class specific request code when you send a break on the host side. The USB-serial-JTAG device will acknowledge reception of that back to the host, but will otherwise throw away that information; it is not possible to detect in firmware that a BREAK was sent from the host.

Note that this is only a restriction of the (hardware) usb-serial-jtag device. If you switch to the ACM mode of the USB-OTG device (using TinyUSB), that should (at least hardware-wise) be able to detect BREAKs.

[second.string]

So your question is actually if/how a BREAK can be detected when using the USB-JTAG serial?

Ideally I think I'd get access to all standard UART interrupts, like single byte received, FIFO overflow, break, etc. Thinking further about it now though, I think I can get by with just the BREAK, handling the rest in firmware with timers and logic.

Note that this is only a restriction of the (hardware) usb-serial-jtag device. If you switch to the ACM mode of the USB-OTG device (using TinyUSB), that should (at least hardware-wise) be able to detect BREAKs.

Hm okay, I was hoping I'd be able to use the built-in USB to serial converter of the S3 chipset to act as a standard UART. If I remove the need to flash the board over USB, is that functionality then possible? I'm not sure if it's possible to use that as a simple serial port without the JTAG aspect as well.

I took a look through the IDF documentation for the TinyUSB-based USB stack and it's bit confusing, but I'm pretty sure I'd want just a standard CDC device as shown here https://docs.espressif.com/projects/esp ... evice.html. If I'm understanding the TinyUSB source code correction (doesn't really look like there are any docs), I should just have to hook this callback to get notified any time the incoming USB signal is signalling a break: https://github.com/hathach/tinyusb/blob ... ice.h#L207. Does that seem right?

Followup question to the CDC-based implementation - if my device is set up as a USB Device using TinyUSB, does that mean I also will not be able to flash over USB without further action (i.e. GPIO0 to ground)? Is it possible to kick the device into the bootloader over that standard USB connection, which would then accept new firmware either through the usb-to-serial peripheral or the USB-DFU mechanism?

[MicroController]

If you go the tinyUSB route, you could also hook into the DTR/RTS events and trigger a restart into the bootloader from software when you see them toggle in the right way, emulating the USB-JTAG serial's behavior.
(Although I'm not sure if switching back and forth between USB-JTAG and tinyUSB is possible without at least unplugging the USB in-between.)

[second.string]

Yeah that's my concern: that once I take over the internal USB PHY for the TinyUSB usage, then I won't be able to easily give it back to the usb-serial-jtag (and vice versa).