cancel
Showing results for 
Search instead for 
Did you mean: 

HAL_UART_Receive_DMA has an unfindable hickup.

JNieu.1
Associate II

Hello,

I'm working with UART Communication between a RPi and an STMG070RB. For the UART communication I'm using the library function HAL_UART_Receive_DMA.

I have an initialize in which the Receive function waits for 3 bytes to be received (My messageheader). After this was received it reads the amount of remaining bytes to be read from the messageheader and then calls the receive function again, but this time to receive the remaining amount of bytes.

This works on a lot of occasions, but at one point gets stuck on the first part, it has received the messageheader, it has read the correct amount of remaining bytes from this messageheader, and then calls the receive to get these remaining bytes (the message body).

So at a random point this part just stop to work, it always receives the header, but then failes to receive the message body. I have checked with a logic analyzer and I am 100% certain the bytes do get send. It seems like my HAL_UART_DMA might be stuck in a state that I cannot find.

Anyone knows what I could check, and what could be going on?

Kind Regards,

Joey

4 REPLIES 4
TDK
Guru

Debug it, when the problem occurs, hit pause and figure out what state it's in. Use GPIO pin toggles to indicate on the logic analyzer which points in the code get hit. Might be the data is being sent while HAL is not yet ready to receive it.

If you feel a post has answered your question, please click "Accept as Solution".
JNieu.1
Associate II

I have debugged it. I know the exact point where it fails to work, it's that it doesn't receive the message body after interpreting the message header.

While it doesn't do it all the time, I can run through this exact same part of code a couple of times (unknown number) with it still working, and then when it comes to the HAL_UART_Receive_DMA, it goes past it and executes the rest of the code in the statement, but it will never receive the data anymore.

It's all in a controlled environment, I control myself exactly when I send the new data, and only do so after the main code has passed the receive part again.

Piranha
Chief II

"Testing shows the presence, not the absence of bugs." /Edsger Dijkstra/

Take a note that such issues can happen because of this:

https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

And yes - that means that almost the whole HAL library is flawed and unreliable.