USART-UART problem with STM32F446

[max.tisc]

hi everyone, i think there are some problems with the UART and USART serials on the STM32f446, to do some tests i used a Nextion display with UART communication connected to channel 1 USART1, the test consists only of changing a page on the display and repeating on a UART output the bits sent by the display and reading them on the PC via a normal USB TTL converter. in the screenshot N1 you can see the data sent by NEXTION, and they are correct, in the screenshot N2 you can see the data sent by the UART channel 4 UART4 and they are not correct, consequently as you can see in the screenshot 3 the data read on the PC do not make sense and of course the page on the display does not change. at first I thought that the USART and UART ports were not fully compatible so I moved the display to the UART5 channel port but nothing changed
I would like to point out that I have been using these displays for quite some time and connected to an atmega2560 I have never had these problems, while I have been testing the STM32 for a short time
I also attach the file sorry if it is rough
Please help me
thanks

[LeighM]

Hi,
First thing to note is that your UART RX interrupt code (RX_232) has far too much processing.
The UART RX interrupt code should be as short as possible, and certainly not wait for more received characters.
e.g. you should only receive one character, store it in a buffer (for later processing), then exit.
Or perhaps have a "state" value that is changed by the value received.
Then use the "state" in the main macro to decide what further action to take, such as displaying data.
Hope that helps.

[max.tisc]

ok LeighM thanks, I did as you suggested and now it works
thanks a lot

[max.tisc]

Hi, I still have some problems with data reception, as you can see from the screenshot to check if the data is stored correctly in the buffer I send them to an external serial port, by pressing the button on the display for the first time I receive the data circled in red and they are not correct, by pressing the second time I record them correctly in the buffer circled in blue and in fact then you can see that the request to change page is sent to the display, by analyzing the data flow coming out of the display the data is always correct
thank's

[LeighM]

Note for Matrix: I think there is a chance that this issue is connected with the fixes done to the F4 series FCDs in v10,
could these be ported back to v9?

edit: Ah, just spotted something in your code, you are setting a flag on any received character, which then causes processing in the main.
So you could be processing before the whole packet has been received.
I haven't had time to look at the protocol, but you might be better setting the flag_232 when you have determined that you have received a complete data packet.

[max.tisc]

ok thanks, your advice is always useful, I eliminated the flag_232, now I modified the code (part in yellow) checking that the 7 bytes have arrived, (I hope I did it right), on the test code it works at every shot, but when I go to bring it back to the more complex code it doesn't work correctly and I have to press the button several times to make it take the correct sequence in red the incorrect ones in blue the correct one, even if the last byte is wrong and the display changes screen because I only check the value of the first 3
could it be the problem of the correction you wrote about?
thanks

[Brendan]

I believe there are fundamental issues with STM32F4.. UART, particularly when RxD hangs for no apparent reason, and erratically so.

I have a program on an STM32F407 running TxD+RxD (no flow control) on two hardware UART channels running at 9600bps. In both cases the UARTS are serviced by ISRs that merely store the received byte to a string and increment an indexer before exit. Furthermore, all internal MCU busses are running at max speed, as defined in CubeMX.

Although the main program services data when the indexer value is >0, the ISR should always take priority over the main program flow to process the next byte.

Whilst the UART is successfully and reliably sending a train of data to PuTTY terminal, I can initially trigger MCU responses by tapping single keys on the keyboard, but only the case for anywhere between one and several key repeats with intervals of a few seconds between each key tap. Thereafter, data continues to stream from the MCU, but responses to keys completely cease.

Never having seen such issues with PICs, I'm trying to establish a succinct resolution, though I suspect it won't be pretty. I'll update if I can find a successful workaround.

[LeighM]

What version of Flowcode are you using?