CDC App stalls on second character in from USB side

[sdzienge]

• Followed top level instructions to clone stm32u5-classic-coremw-apps repo
• Drilled down to STM32U575_CDC_Standalone project
• Opened Project.eww using IAR Embedded Workbench v 9.40.1
• Allowed migration of project to new IAR version
• Rebuild All
• Loaded onto NUCLEO-U575ZI-Q board
• Clicked run
• Opened Terminal for com12 (STLink VCP/Uart side) using 115200, 8N1, None
• Connected USB-C cable
• Opened terminal for com13 (newly connected USB side) using 1215200, 8N1, None
• Type characters in com12 terminal, all show up on com13 terminal
• Type characters in com13 terminal, only the first shows on com12 terminal

When typing 1 character at a time I see that the first character is successfully transmitted, but the second never completes. Second character is received, and a successful start of the DMA transmission is indicated, but no events fire (half, complete, or error). This locks up the receive side of the USB as USB_CDC_ReceivePacket is never called. Communication in the other direction continues to work fine. Characters received by the uart (STLink VCP) always results in characters being transmitted on out the USB CDC side.

[sdzienge]

Problem seems to be with using HAL_UART_Transmit_DMA for transfers of len = 1. I made the change below and the stalls went away. I could have used HAL_UART_Transmit_IT and used the uart ISR to call HAL_UART_TxCpltCallback to make it more symmetrical with the DMA path, but that seemed unnecessary.

static int8_t CDC_Itf_Receive(uint8_t * Buf, uint32_t * Len)
{
if (*Len == 1) {
HAL_UART_Transmit(&UartHandle, Buf, Len, 0);
USBD_CDC_ReceivePacket(&hUsbDeviceFS);
} else {
HAL_UART_Transmit_DMA(&UartHandle, Buf, *Len);
}
return (USBD_OK);
}