Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[Gen 3] Always check ongoing RX DMA transaction when reporting number of bytes available in RX buffer #1758
This is a "bug" in how we handle partial DMA transfers. We commit pending DMA data only if the RX buffer is empty, so you would see a smaller number in
Originally issue was reported in https://community.particle.io/t/error-serial1-available-argon/48380/4
Always check ongoing RX DMA transaction when reporting number of bytes available in RX buffer.
Steps to Test
I am testing a loop with identical code on both a Xenon and Arduino MEGA. Serial Sensor is running at 57,600 baud and an update frequency of 194Hz.
Here is a summary:
So as you can see, something much more problematic is going on …
I honestly don't. Could you create an issue and provide some example of how this can be reproduced?
Are you using flow control? Is your Xenon doing something else other than reading the Serial port? Do you use threading? If no flow control is enabled and Xenon also does other things you may simply be not reading out the data from the internal RX buffer fast enough causing overflows and errors you are seeing. You could try using
We have a set of tests that verify the USART implementation and also on both the Boron and Argon the connection to the NCP (cellular modem or ESP32 for WiFi) relies on USART, so I would expect we would have caught any issues causing data loss/corruption.
May 16, 2019
1 check passed
I added in the community the post below but not in this forum.
To answer your questions, I am not using flow control. The Xenon is only reading from the serial sensor, but I keep getting the panic resets per my post below. I have tried SYSTEM_MODE(MANUAL) and SYSTEM_THREAD(ENABLED); but it did not help.
I think that most likely reason is buffer overflow. BTW, when the same code reads from an i2C sensor (that is updating at 80 Hz), the code NEVER crashes. This problem occurs when interfacing to a fast serial sensor (190 Hz in my case).
I hope this helps.
_I moved the blocking loop in my code to the loop() routine from setup(). When I did that, I found that I am reading the full sensor update speed. So it looks like the OS is doing something during setup() which takes some processor time even with SYSTEM_THREAD(ENABLED);. I want to thank Particle for the 1.2Beta which is a major improvement.
I am still getting some panic, hard_fault every about 15-25 minutes (sometimes after a couple of hours). There remain issues (apparently due to UART buffer overflow) during setup() where the sensor readings are missing/incorrect. In my application, this is serious because some major operational parameters are re-calculated during each restart. I would appreciate the community’s help for a workaround.
Hopefully these remaining issues will be resolved as 1.2 matures._