UART RX buffer issue after buffer overflow

  • Summary: overflowing the UART receive buffer causes an offset in the ring buffer pointer so further use of the UART returns incorrect data.

    From this thread. Reproduced by me this morning without difficulty. The GPS module discussed in the thread is not relevant/required to reproduce the issue.

    Test setup: External device (I used an Arduino) setup to send n chars to the FiPy UART. I've only tested this on UART 1 so far (P3/P4).
    Test init: UART(1, baudrate=9600, bits=8, parity=None, stop=1, timeout_chars=10, pins=('P3', 'P4'))

    (sysname='FiPy', nodename='FiPy', release='1.15.0.b1', version='v1.8.6-849-baa8c33 on 2018-01-29', machine='FiPy with ESP32', lorawan='1.0.0', sigfox='1.0.1')

    Sending 50 bytes results in any() showing 50 and readall() returning correct data (as expected).

    Sending 999 bytes results in any() showing 480 and readall() returning truncated data (as expected?).

    However, this overflow appears to cause some corruption or offset in the ring buffer pointer. Any subsequent data is received and the bytes correctly counted when checking any(), BUT reading the data with read(n) or readall() returns previous data from the buffer before some of the new data. eg (sent 20 chars):

    >>> uart.any()
    >>> uart.readall()

    In this case, "xxx" was previous data still in the buffer, the data actually received and counted was "01234567890123456789".

    De (&re) init of the UART does not fix it once the buffer is in this state. Calling machine.reset() and initializing the UART from fresh seems to be the only way to sort it.

    This exact UART behaviour is discussed here (different ESP32 OS but they do come up with a fix), and perhaps more usefully here (recent ESP-IDF bugfix).

  • I would also be interested if this problem was fixed or not?

    I'm working on a project where i need to read data with up to 2100 bytes at once and it seems that data (about 500 bytes) gets lost somewhere.
    I have no problems with smaller chunks with about 80bytes.

  • @daniel was this problem actually fixed?

    I think I'm having a similar issue on the latest LoPy4 firmware.

  • @daniel

    Awesome thanks!

  • @nathanh it will be a standard firmware update.

  • @daniel

    Sorry for the dumb question, but will this be a firmware update which we simply use the firmware updater tool on our devices or will we need to build our own off the repo?

    Also, thanks a lot to everyone involved in getting this sorted, will save me a lot of headaches going forward!

  • daniel ADMINISTRATORS less than a minute ago
    Hello guys,

    The issue fixed in the IDF is definitely affecting us. We will merge that patch and will be available for our next release this week.


  • I believe I am experiencing the same issue:


Hello World?

Pylife on Kickstarter - November 2018

Back Us On Kickstarter >

Pycom on Twitter