alejoseb / Modbus-STM32-HAL-FreeRTOS

Modbus TCP and RTU, Master and Slave for STM32 using Cube HAL and FreeRTOS
GNU Lesser General Public License v2.1
519 stars 182 forks source link

Flipped two lines in UARTCallback.c #103

Closed Noxrem closed 3 months ago

Noxrem commented 4 months ago

Since there was always a wrong number of bytes received I looked at the implementation of the interrupt and found that some value was added to the ring buffer before the UART receive register was read. I flipped those two lines and now it works properly.

alejoseb commented 4 months ago

Hi, What is the scenario where you found this issue?

What do you mean by "some value was added"?

The receive buffer is already read by the HAL library before entering the callback code. So, the first logical step is to copy that data to the ring buffer and then activate the interrupt for the next character, not as you suggested.

Eventually this issue can happen if a character arrives before the kernel is initialized. You can try moving the ModbusStart() function from the main() to a place in your code that is executed after the kernel is started. For example at the beginning of one of your freeRTOS tasks.

Noxrem commented 3 months ago

Hi alejoseb, I use your library a little altered (removed the DMA, TCP and Master code) on a NUCLEO-STM32G491RE dev board as a slave in interrupt mode (no DMA). When I received a message, there was an unexpected value in the ring buffer before the slave address. I think the problem comes therefor that the value from the HAL receive buffer is not loaded yet into the mHandlers[i]->dataRX when the RingAdd() is called. So then there is a random value added to the RingBuffer.

This problem got resolved for me once I flipped these two lines of code, to make sure there is a value from HAL_UART_Receive_IT in the mHandler[i]->dataRX variable before I add it to the ring buffer.

Hope you understand my problem and feel free to ask further questions.

alejoseb commented 3 months ago

That assumption is incorrect. The HAL library triggers the callback only after having the received data copied to the receiving buffer.

If you modify the library then your issue may be related to your changes. So I recommend that you test with the library as is, and if you still see the issue then I can investigate further.

I am closing this PR since your issue has not been reported previously and cannot be reproduced in the standard library.

alejoseb commented 3 months ago

Error is not reproducible in the current library version