-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UART HW DMA ( UART Communication based on HW DMA ) - Buffer Overflow in STM32H743 Controller #76801
Comments
Hi @adityamilinddesai-eaton! We appreciate you submitting your first issue for our open-source project. 🌟 Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙 |
hey sharing a code snippet will help a lot to comment. |
|
Hi @adityamilinddesai-eaton, First, when we have a buffer overflow, there are three events that occur after reception. First, the buffer is disabled (uart event type = UART_RX_BUF_RELEASED), then the communication is disabled (uart event type = UART_RX_DISABLED), and then there is a request made by the driver to have a second buffer (uart event type = UART_RX_BUF_REQUEST). Then it is recommended in zephyr when we make a UART communication, to make a copy of the buffer to perform future processing there if necessary. To avoid the carry over the byte, we can set up a flag that will notify us when receiving the next message that there was an overflow during the previous one. Then with the main buffer copy we could remove the extra byte in the message and display the result. Here is an example :
Nota: This code only handles the error case mentioned when there is a buffer overflow |
I haven't looked much into this, but in zephyr there is a special mechanism to continuously receive data in case there is an overflow, that could be a solution to the problem too. Here is the link : we will have a configuration a bit like this: case UART_RX_BUF_REQUEST: The global array rx_second_buffer will contain the data history for the defined size. Finally, I saw that you use the device_get_binding() function, unless your application requires it, Since version 3.2, zephyr suggests that we use the DEVICE_DT_GET() function instead as mentioned in the release note |
@adityamilinddesai-eaton Does this proposal help ? |
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
We are using zephyr V3.6.0 and SDK version 0.16.5-1.
We are written code for Uart HW DMA for STM32H743 controller.
Assuming a buffer of 256 Bytes, A message sent with 257 bytes will cause an overflow event to be generated.
Example:
Sent Message: "Call me Ishmael. Some years ago never mind how long precisely having little or no money in my purse, and nothing particular to interest me on shore, I thought I would sail about a little and see the watery part of the world. It is a way I have of drivingEO"
Echoed Message: "Call me Ishmael. Some years ago never mind how long precisely having little or no money in my purse, and nothing particular to interest me on shore, I thought I would sail about a little and see the watery part of the world. It is a way I have of drivingE"
This event is serviced in our driver as well as the uart_stm32 driver. The next message sent by the client will be echoed with the overflow byte (O from #1 Sent Message) added to the beginning as seen here:
Sent Message: "Call me Ishmael. Some years ago never mind how long precisely having little or no money in my purse, and nothing particular to interest me on shore, I thought I would sail about a little and see the watery part of the world. It is a way I have of drivingE"
Echoed Message: "OCall me Ishmael. Some years ago never mind how long precisely having little or no money in my purse, and nothing particular to interest me on shore, I thought I would sail about a little and see the watery part of the world. It is a way I have of driving"
#Notice that the 'E' character has caused another overflow. If the user/client uses the entire buffer for every expected message, and has at least one overflow, this could cause some confusion.
How to avoid the carry over byte.
The text was updated successfully, but these errors were encountered: