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 ?
7
-
\$\begingroup\$ Is there a reset line to the TFT that you can assert after the MCU powers up? It looks like you are expecting the TFT and MCU to be ready at exactly the same time after a reset, which is probably not the case. \$\endgroup\$– Ron BeyerApr 20, 2020 at 16:19
-
\$\begingroup\$ @RonBeyer I'm using RST pin of MCU and yes I'am expecting that. So, how I can handle this mismatching problem. I always want to get this Rx Data in right order but how ? If uart message includes start and stop bit, there should be no mismatching right ? \$\endgroup\$– IHKApr 20, 2020 at 16:27
-
\$\begingroup\$ Start/Stop bits are for individual bytes, not an entire message. If you send a reset to the TFT after the MCU restarts you should be assured that the data comes in the correct order, it isn't clear if you are doing that or not. \$\endgroup\$– Ron BeyerApr 20, 2020 at 16:31
-
\$\begingroup\$ @RonBeyer I never touched TFT. It sends its own message periodically. I am resetting stm32f4. I can't reset TFT. Are there any method that I can parse the message in right shape ? How can prevent these shiftings of buffer's content. \$\endgroup\$– IHKApr 20, 2020 at 16:38
-
\$\begingroup\$ @IHK - Hi, (a) "TFT [...] sends its own message periodically" That doesn't come from a display, so I guess there is something like an HMI input (to MCU) stream e.g. touch screen etc. Is that correct? Please edit the question and add details (e.g. datasheets) of the TFT display and explain this non-stop data stream e.g. touch data or whatever, and include datasheet links for those devices too. (b) What is the context of this e.g. new design, or existing design you are changing? Are you working on a prototype or final hardware? (c) What control do you have over the datastream to the MCU? \$\endgroup\$– SamGibson ♦Apr 20, 2020 at 17:04
|
Show 2 more comments
1 Answer
\$\begingroup\$
\$\endgroup\$
5
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(whereAAis a byte from packet A,FFis the end of packet marker that you mentioned for packet A,BBis a byte from subsequent packet B).
answered Apr 20, 2020 at 17:30
-
\$\begingroup\$ Sam thank you I will try this approaches and inform you. \$\endgroup\$– IHKApr 20, 2020 at 18:12
-
\$\begingroup\$ @IHK - FYI I have updated my answer and removed option (3) with an explanation. My personal experience has been with options 1 and 2. Now I remembered why I couldn't use option 3 :-) Please update the question to add links to the datasheets for the display and whatever is producing that datastream, when you can. My earlier comment requesting more context from you (e.g. are you programming a prototype or final product etc.) is related to whether you could add additional hardware (e.g. to control the power supply to the display) at this stage. Thanks. \$\endgroup\$– SamGibson ♦Apr 20, 2020 at 19:25
-
\$\begingroup\$ firstly i didn't understand option 3. I have to ask something I traced dma buffer. When wrong sequential data filled DMA buffer. It is going on like that and data are not ranked as must be later. Why ? Secondly, I will try polling method after power on untill valid ranked data will be received so, I will write an if statement to control states above and Dma will be set in if statement right ? \$\endgroup\$– IHKApr 20, 2020 at 19:56
-
\$\begingroup\$ @IDK - Sorry, but I didn't understand your comment before the word "Secondly". After the word "Secondly", then yes, you could use
ifstatements to count the number of 0xFF bytes, as each byte is received (I would use a simple counter, which is reset to zero if the byte received is not 0xFF, and increment after each 0xFF). When the counter ==3 then you have received 3 consecutive 0xFF bytes, Your question about DMA being set in anifstatement is an implementation detail, which depends completely on your code. If you have used UART DMA already then, after 3 x 0xFF, just use it as before. \$\endgroup\$– SamGibson ♦Apr 20, 2020 at 20:22 -
\$\begingroup\$ Okey Sam this is really helps me. @SamGibson. Now, I know what will I do. \$\endgroup\$– IHKApr 20, 2020 at 20:48