I just posted UART can lose data under heavy loads on Task Tracker. Feel free to discuss and make suggestions here.
UART can lose data under heavy loads was updated.
Status went from Proposed to Open.
Priority went from Unassigned to Minor.
@ John - I can state the following, maybe it helps in bug tracing:
For me, transmitting chunks of around 300 Byte every 100 ms in range from 57.600 to 460.800 bauds works reliably now with my Raptor board. Each chunk takes between 5 to 50 ms to transmit, depending on the chosen baud rate.
Don’t know if this already falls under the category “heavy loads”.
When estimating application runtime needs versus required time for data chunk processing, I considered that the underlying maximum, fixed NETMF serial buffer size is 1024 bytes. Hope that this is correct? I use the rs232.Port.DataReceived event and with every event I enqueue all bytes to read at that moment in a System.Collections.Queue. Since I am doing so, I didn’t loose any data anymore, as it was the case before without additional FIFO queueing.
Nevertheless, as long as I used socket 12, I regularly faced HAL resets w/out any exception-, overflow- or GC-message at the latest after transmitting above said chunks over period of 30 to 300 seconds.
But since I use socket 11 I never had any problems anymore, application runs permanently without any resets or data losses. Must, in this special case, have something to do with socket 12.
@ Harald - The underlying serial buffers differ for each board. For the G400, I believe it is 4KB TX, 16KB RX. Thanks for the information. We will try and look into socket 12 as well.
UART can lose data under heavy loads was updated.
Status went from Open to Closed.
I am interested in knowing how this was fixed, and what systems it might have impacted…?
Since the staus is “Rejected” I would guess it is not fixed.
Hopefully it will get fixed withe the new Network stack Approach by MS