2023-10-18 06:48 PM
Solved! Go to Solution.
2023-10-19 05:30 PM
By default, cubeMX assigns USART2 Tx and Rx to PA2 and PA3. According to the STM32 manual, for virtual communication (USB), only PA2 and PA15 are used. I had to change PA3 to PA15. Now the program works.
2023-10-18 07:10 PM
What board is this? How are USART1 and USART2 connected externally? Where is the signal on UARTx_RX coming from? Your code doesn't do anything with the received data. How do you know it's not working?
Probably a hardware issue. Either the pin isn't connected, or the signal isn't coming in where you think it is. Or possibly a misunderstanding of what should be happening.
2023-10-18 08:12 PM
I'm using the STM32F042K6. The received data is transmitted back through the same UART module. That's if there's any received data. The program for that is inside the main function.
2023-10-18 08:52 PM
Those are blocking functions. If you want to receive at the same time as you're transmitting, you'll need to use HAL_UART_Receive_IT or HAL_UART_Receive_DMA.
Perhaps look at some existing examples:
2023-10-18 09:09 PM
2023-10-18 09:45 PM
You haven't shown any code for uart1 so we don't know how you're trying to receive data.
What you've posted works for uart2. However, HAL_UART_Receive is blocking and with max timeout, you're going to be waiting a little over 49 days before it returns or you receive 12+ bytes.
If you're receiving variable length strings then use HAL_UARTEx_ReceiveToIdle_IT and HAL_UARTEx_RxEventCallback or HAL_UARTEx_ReceiveToIdle_DMA instead.
2023-10-19 06:26 AM
I think you are ignoring the fact that the UART_MAX_DELAY flag is used in the program to block until there's data recieved. That's what I want to do. I want to block until the UART recieves data.
2023-10-19 07:37 AM
> The received data is transmitted back through the same UART module.
If RX and TX are tied, as you said, you absolutely do need DMA or IT to work. Otherwise, your receive function blocks waiting for data and your transmit function never gets called. Debug your code, hit pause, see where it's waiting.
2023-10-19 09:19 AM
No, i'm not ignoring. I'm just stating that you have to wait until the function returns and until then, you can't do anything else in the background. That's pretty inefficient Use HAL_UARTEx_ReceiveToIdle_DMA and in the interrupt callback you can transmit what you received. Whilst you can do tons of other stuff in the background at the same time.
2023-10-19 02:26 PM
If you're receiving variable length strings...
There is no "if" for stream interfaces and especially the simple ones like UART. A byte can always be lost because of wiring issues, noise, delayed interrupts, CPU/DMA/bus overload etc. If the code doesn't deal with it gracefully, then it's broken and the device is not reliable.