First byte of USART data received through DMA is not the right one

[Hugues Libotte]

Hello.

I am using the STM32F030 for a sensor with a RS485 interface.

In my tests, I am sending a 8-bits message (constant value) to the STM32 in a loop. When I look at the data received, the last byte is at the first place, always. There is never any other or additional shift.

I can understand it is byte remaining from the previous comm and missed out from the previous reading but why is it so stable (always one byte and always the correct one).

Any idea about the reason of this ? And more usefull, do you have any method to clear the DMA buffer before starting reading ? Would you recommand the use of a circular buffer for the DMA ?

On one side (transmitter)

message_TX[0] = 0x02; ...; message_TX[6]= 0xDE ; message_TX[7] = 0xAC;

HAL_UART_Transmit_DMA(&huart1, (uint8_t*)message_TX, 8);

On the other side (receiver)

HAL_UART_Receive_DMA(&huart1, (uint8_t *)message_RX , 8);

And I get the following data in message_RX[0] = 0xAC (always) and message_RX[7] =0xDE (always)

Any suggestion for me ?

[Hugues Libotte]

In addition... if I read 9 bytes, I was expecting a progressive shift in the position of this first byte but it is not the case. I read the expected sequence from byte 1 to 8 and byte 0 is still containing the value from the previous comm (as I understand it)...

[Issamos]

Hello @Hugues Libotte 

Maybe one of those 3 errata is the source of your problem.

 

 

 if not, i Suggest you to do the send all the 8 bytes byte by byte using a for loop that send the byte 1 juste after receiving an acknowledge that the byte 0 was well received...

Best regards.

II

[Tesla DeLorean]

I wouldn't receive multiple bytes in this way, real difficult to re-sync. Use a protocol with patterns that allow for stream to be resynced, and integrity checked.

RS485, where receive and transmit connect together? In a loop-back or one wire mode sense?

[Hugues Libotte]

Yes, it is for RS485 but in full duplex. I agree about the pattern but, clearing the UART register  content would be easier. I have several 100ms - even more-  between two communications so no hurry to take care of this.

[Hugues Libotte]

Hello. Thanks !

Maybe  the third one but as far as I read, it seems the HAL_UART_TRANSMIT_DMA and HAL_UART_RECEIVE_DMA deals with uint8 and uint16. But what to set up in the CubeMX config panel.

[Issamos]

You have to do exactly as sayed in the errata.

Best regards.

II

[Hugues Libotte]

In the HAL file, there is

AL_StatusTypeDef HAL_UART_Transmit_DMA(UART_HandleTypeDef *huart, const uint8_t *pData, uint16_t Size)

This is 8-bits data...  and there is no other suggestion than using 32-bit... but does it mean that the HAL files are wrongly written ? Because, it is written in "write access" so only when I send (TX) bytes... not at the reception (RX) as there, I do not write in the DMA registers....

Do you have example linked to this errata ?

Bye,

H

[waclawek.jan]

Give us more context. Does the sensor transmit data all the time, or only after the STM32 asks for it? Are the DMA set as circular?

At any case, you should do what Clive recommends. DMA is not that useful for UART, and just hanging on some rx-complete callback expecting flawless data to appear automagically in a buffer is not sufficient.

JW

[Hugues Libotte]

Hi,

The sensor is a RS485 slave so it answers to the request of my uC. This request occurs every 500 ms (so really not in a hurry). I tested both DMA in circular and not : same issue.

I can agree that DMA is not so mandatory here... but this issue is strange and I would like to get it operationnal for a future use in another project where we would really need this.

Bye

H