Device UART timing issue STM32 - Page 1
Forum section: electronics / general

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 08:28:21 am
content: Good morning,I have to communicate with a commercial device via UART. I have no access to the device software, nor any way to modify its behavior.This device is old and it already does this communication with an old DOS pc. I want to replace this old pc with a micro controller that does the same.I tapped the communication between the two with a logic analyzer and got all the messages I have to send to emulate the pc.I decided to use a STM32G0B1KCT. The device actually outputs the data in RS232 so I used a MAX3232 to convert it back to TTL UART.In the pc's software when it's communicating with the device it says that the baud rate is 19200. Which the logic analyzer baud rate detector confirms.So I set up the STM to 19200 and tried the communication. The device responds a 11 byte data chainbut my STM only get the first one and then times out.I checked the communication between the STM and the device and I noticed that the bit length of thestop bitof the device response is a little bit off (pictures)For a 19200 baud rate it should be around 52us (the STM is) but the stop bit width of the device is around from 68 to 72us. I don't know if that could make the STM to time out after the first byte.I tried setting a stop bit length of 1.5 but the result is the same. Anyway, a stop bit of 1.5 would be around 78us. That is quite far from the 68 that the device sometime sends.I tried receiving all bytes at once:Code:uint8_t response1 = {0};uint8_t r1 = HAL_UART_Receive(&huart1, response1, 11, 1000);'r1' is3after execution meaningHAL_TIMEOUTI also tried to receive byte by byte:Code:uint8_t response1 = {0};for(uint8_t i = 0; i < 11; i++){uint8_t db = 0;HAL_UART_Receive(&huart1, &db, 1, 100);response1 = db;}But the result is the same,response1has the first data byte and all other bytes inresponse1are '0';The image below shows the response of the device after the conversion to TTL. As you can see the data bit length is 52us (consistent with 19200bit/s baud rate)But the stop bit is quite longer.Am I doing something wrong? Is there a way I can go around this problem and get all the data correctly?Thank you!Edit: STM UART config:(Full disclosure) I don't understand many of this setting, so I might have something configured wrong. If you see something off please adviceEdit2:I sent the same 11 bytes from the STM to the device, I then captured both and put them side by side to compare.As shown in the image, the data is quite similar, the only difference is that the device's stop bit is a bit longer, causing the message end to drift a little bit to the right.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 21, 2023, 08:40:37 am
content: If you try an assortment of USB-UARTS do they all accept that ok ?Looks fine to me.Maybe check if the STM is set for two stop bits ?usually that defines TX only, tho I did recetly find my first device where 2 stop bits mattered on RX : the WCH CH347

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 08:57:15 am
content: Quote from: PCB.Wiz on August 21, 2023, 08:40:37 amThank you for your answer, I only have one USB to UART converter, I tried and it seems to receive the data correctly.The STM is set for 1 stop bit.I'll add a picture of the UART configuration in the post

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 21, 2023, 09:06:30 am
content: Quote from: BorisRap on August 21, 2023, 08:57:15 amThat seems to say 'including parity' but the capture does not show parity.oops misread, there is a separate parity line.Try setting the same as the uart you know worked.Also send a dummy byte from the STM at init, to confirm you have the UART settings right.If that's ok, you can also self test using loop-back and send the 11 test bytes to itself.not sure what DMA on RX error means, or overrun, so you could try disable of both those, at least initially until you get a pulse.Another sanity test, is to simply echo every RX byte, back out TX, in a very simple tight loop. No interrupts and no other code.

author: wek
author_rank: Frequent Contributor
timestamp: August 21, 2023, 09:10:07 am
content: Longer stopbits don't matter.Read out and check/post content of UART registers (after the problem happens, note that observing UART registers in debugger isintrusive). If you run at low system clock, maybe UART does not pick the next byte fast enough,overruns and stops receiving. I don't know what Cube/HAL does in that case, I don't use Cube.JW

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 09:45:27 am
content: Quote from: PCB.Wiz on August 21, 2023, 09:06:30 amThanks for your answer,I sent the same 11 bytes from STM32 to the device to check the configurationI'll attach the picture to the main postThe config of the STM and the UART to USB converter are the same (as far as I understand)I though a timer running in the background may intervene and I disable it, so no other interruptions are taking place during the execution of theHAL_UART_ReceiveI tried disabling DMA on RX and overrun with no results.

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 09:53:46 am
content: Quote from: wek on August 21, 2023, 09:10:07 amThanks for the answer,I tried executing it in release and the result is the same.I don't know quite what to check in the registers, sorry. I did a picture of the state of&huart1right after the receive

author: wek
author_rank: Frequent Contributor
timestamp: August 21, 2023, 10:22:53 am
content: UART registers are under "Instance" there (and please switch to hexadecimal); or just find the Peripheral registers (SFRs) view/window in your IDE.By "checking" I meant reading out the values and checking against the registers' description in Reference Manual (RM).JW

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 10:30:10 am
content: Quote from: wek on August 21, 2023, 10:22:53 amThanks for the teaching!Here's the state of the USART1 SFRs, I'm gonna check it using the RMThanks!

author: wek
author_rank: Frequent Contributor
timestamp: August 21, 2023, 10:46:23 am
content: You appear to run at system clock of 64MHz so that should not be the issue.My guess is, that the Cube functions time out *before* you receive the first byte. Make sure your Cube's 1kHz ticker runs at 1kHz - test with some pin toggling and HAL_Delay() or how is that function called.JW

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 11:50:07 am
content: Quote from: wek on August 21, 2023, 10:46:23 amThe tciker runs ok, and the main clock is running at 64Mhz correctly.After the execution of theHAL_UART_Receivethe buffer correctly contains the first byte of the data stream (0x3E) but all the other bytes in the array are 0x00 so the timeout happens during transmissionThanks!

author: BorisRap
author_rank: Contributor
timestamp: August 21, 2023, 12:14:07 pm
content: Thanks everyone again for the help.I found the issue, apparently, the execution of theHAL_UART_Receivewas done after the message was sent, due to incorrect time management in my code.I didn't notice since I got the first byte of the chain in the UART receive, apparently that's the behavior of the peripheral. Leading me to think that the receive was taking place at the right time.Thanks again and sorry for the inconvenience