There is a communication between TFT NX8048p070-011r and my STM3F4 over UART. TFT sends 8byte data continuously and MCU receives by using circular DMA. I apply a parser to those data in Txclptcallback. When I toggle the RST pin Rx buffer contents are shifting for ex. if Rx buffer is [0,1,2,3,4,5,6,7], when RST toggling occurs buffer comes like [6,7,0,1,2,3,4,5]. This problem occurs randomly. Baudrate:115200. There is no problem at transmitting. What will I do now ?
TFT's data frame consist of 8 bytes. First byte indicates types of event like touch event, picture or page changing events, next 4 bytes are stored for Data and last three bytes includes 0xFF 0xFF 0xFF
We are still missing some information (datasheets etc.), but based on your comment, you have a way to synchronise with the datastream from the display - something like:
After MCU is reset, do not use UART DMA to collect the display datastream into RAM. Instead loop, reading each byte one at a time, until you have received 3 consecutive 0xFF bytes. That signals the end of that 8-byte "packet".
That may slightly delay MCU startup, but if this datastream is important, then you may have to wait for the datastream to become usable,
Then, when you have recognised the end of the previous 8-byte "packet", enable the UART DMA to collect the next packets into RAM, as before, and you will be "in sync" with that datastream.
This all assumes that 3 consecutive 0xFF bytes will not occur, except as the last 3 bytes of an 8-byte "packet".
Another approach, as already mentioned in comments, would be to reset the display controller (or whatever is sending that datastream) under MCU control, after the MCU resets (e.g. via a reset line, or even by performing a power-cycle of the display).
Yet another approach is to collect the UART data using DMA immediately after the MCU is reset, even if that datastream is not synchronised with the start of the DMA buffer. Then add more intelligence to your parser, using your knowledge that the last 3 bytes of each "packet" are 0xFF.
Again, this assumes that 3 consecutive 0xFF bytes will not occur, except as the last 3 bytes of an 8-byte "packet".
I've deleted option (3) since, if each 8-byte "packet" is only transmitted once, then a "non-synchronised" sequential 8 bytes, will contain data from 2 separate packets, which might be unrelated e.g.
AA AA AA FF FF FF BB BB(where
AAis a byte from packet A,
FFis the end of packet marker that you mentioned for packet A,
BBis a byte from subsequent packet B).