0
\$\begingroup\$

I am working with STM32F7 mcu running at 160 MHz, I am also running UART at 160 MHz in interrupt mode to receive data, but in DMA mode to send data. My program also runs 3 SPI and 1 I2C in DMA mode to receive data (every ~1ms), I am running my code bare metal (No RTOS). I read data, create large buffer (around 1900 bytes) and send it every 30 ms at baud rate 1516800.

After testing data transmition via UART, it worked. Now I wanted to implement a feature: Read data on I2C and SPI and send via UART only when received correct command via UART_IT mode (Because I ran out of DMA channels). And here is my question, I tried sending 12 bytes of data (command + payload + crc) with same baudrate from PC to my device and read it with UART_IT, and most of the time it worked, but sometimes I received not full packet (10 bytes out of 12, 4 out of 12 etc.). Then I tried to always receive only 1 byte instead of all 12 and fill temp buffer and process it when it is full, but this gave same results.

I come to conclusion, that my baudrate is too fast to handle for UART interrupt mode, but is there any solution to this problem? Is my conclusion correct? How can I overcome this problem and always receive 12 bytes on Baud rate of 1516800 in URT interrupt mode? Maybe solution is to just spam commands from PC until whole buffer is received on mcu, but this might require to implement some sort of acknowledgment from mcu, which is doable, but might be overkill.

UPDATE: I have checked error bits of UART and found that ORE (Overrun Error bit) is present, so my data is coming faster than mcu can process it.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Are you using receive FIFO on UART? \$\endgroup\$ Commented Aug 22 at 10:04
  • \$\begingroup\$ No, just raw HAL_UART_RECEIVE_IT function to a buffer and later check that buffer if whole packet was received (during debugging). Is this some sort of feature or parameter to enable FIFO ? \$\endgroup\$ Commented Aug 22 at 10:10
  • \$\begingroup\$ Just asking if you use the hardware FIFOs or not. I don't know which exact STM32F7 you are using, why you are running it only at 160 MHz and which USART or UART you are using and why, or if that specific USART/UART has hardware FIFOs or not. \$\endgroup\$ Commented Aug 22 at 10:13
  • \$\begingroup\$ I am using stm32F746IE mcu, It does not have any FIFO parameter on UART configuration screen. I am using only 160 MHz, because my device does not have HSE, only HSI, so I do not want to loose stability on higher frequencies. I am using UART7, because this was a requirement by the hardware of my device (that is way I do not have any DMA channels left for this UART). \$\endgroup\$ Commented Aug 22 at 10:28
  • 1
    \$\begingroup\$ You have roughly 1000 cycles to process a byte at that speeds, that should be sufficient to handle the incoming bytes (I had 260 and that was enough). Instead of coming to a conclusion, you can also check the error bits in the UART and see if you actually encounter the overflow error, which would hint at too slow processing or if some other error is registered. Make sure in your system design, that the UART interrupt has high enough priority that it is not blocked by others for too long. It's hard to give a definitive answer or help without a minimal working example code. \$\endgroup\$ Commented Aug 22 at 11:10

1 Answer 1

Reset to default
0
\$\begingroup\$

So It was probably a interrupt conflict type of bug. I configured UART RX interrupt priority to be highest and all others to be lower by 1 (since I need to read data only once, I can make it highest priority interrupt) and this seems to solve my problem, now I accept every packet that I send, not the best solution if I would require to receive data via UART constantly, but to start some process only once in a life time will do. Conclusion, use DMA whenever you can when working with high speeds, long packets and multiple protocols.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Don't forget to test receiving and transmitting at the same time. If your DMA routine masks interrupts while it's transmitting (a fairly common practice), then bytes being received at the same time could be dropped due to the interrupt routine not being called. \$\endgroup\$ Commented Aug 23 at 1:03

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.