You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: