Skip to content
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

[Gen 3] Always check ongoing RX DMA transaction when reporting number of bytes available in RX buffer #1758

Merged
merged 2 commits into from May 16, 2019

Conversation

@avtolstoy
Copy link
Member

commented Apr 29, 2019

Problem

SerialX.available() may report smaller number of bytes available in RX buffer than actually received, until the data is read out. There is no data loss though.

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 available() that wouldn't change until read out and then partially completed DMA transfer would be commited.

Originally issue was reported in https://community.particle.io/t/error-serial1-available-argon/48380/4

Solution

Always check ongoing RX DMA transaction when reporting number of bytes available in RX buffer.

Steps to Test

Run the wiring/serial_loopback2 test.

Example App

N/A

References


Completeness

  • User is totes amazing for contributing!
  • Contributor has signed CLA (Info here)
  • Problem and Solution clearly stated
  • Run unit/integration/application tests on device
  • Added documentation
  • Added to CHANGELOG.md after merging (add links to docs and issues)

  • [enhancement] [gen 3] Always check ongoing RX DMA transaction when reporting number of bytes available in RX buffer #1758

@avtolstoy avtolstoy added this to the 1.2.0-beta.3 milestone Apr 29, 2019

@avtolstoy avtolstoy requested a review from sergeuz Apr 29, 2019

@jimmie11

This comment has been minimized.

Copy link

commented May 7, 2019

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:

1) 20% erroneous readings on Xenon. Of 1000 readings, about 202 had no read.
2) Read frequency on Mega (194, i.e. full). On Xenon, ready frequency is 80Hz.

So as you can see, something much more problematic is going on …

@avtolstoy avtolstoy modified the milestones: 1.2.0-beta.3, 1.2.0-rc.1 May 13, 2019

@sergeuz sergeuz added ready to merge and removed needs review labels May 15, 2019

@avtolstoy avtolstoy force-pushed the fix/gen3-usart-available branch from 2894d4a to f4e2a02 May 16, 2019

@avtolstoy

This comment has been minimized.

Copy link
Member Author

commented May 16, 2019

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 SYSTEM_MODE(MANUAL) and not establishing the cloud connection and see if that resolves the issue for you.

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.

@avtolstoy avtolstoy merged commit 1734937 into develop May 16, 2019

1 check passed

continuous-integration/travis-ci/push The Travis CI build passed
Details

@avtolstoy avtolstoy deleted the fix/gen3-usart-available branch May 16, 2019

@jimmie11

This comment has been minimized.

Copy link

commented May 16, 2019

@avtolstoy

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._

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.