After my software has been running for about 24 hours I suddenly get a blank LCD with BUFFER OVFLW on the top left.
The main code is still running. In fact, all threads are still running as I can breakpoint into them and step so I know they are all working. Wifi is still working, serial to both the modem and Zigbee are still working.
It messes up the dislplay as it keeps clearing to show the error. All the graphics get drawn on the display except the background is now black.
Lastly, if I breakpoint the code, the error continues to refresh on the LCD so it has to be coming from outside my code.
Anyone have any clue as to were this error originates from?
Update.
I have noticed just now before it finally came up with the error that there was almost a continuous output to debug from the garbage collector. Maybe in my code somewhere.
Will have a look at the HTTP handler as it appeared just after I hit it it a few times from the browser.
Sounds like you might have a memory leak or very close to the limit of available memory.
I have the error now and I can see the GC on debug showing loads of free memory. See below.
This is the output from the GC. What’s the entry for BINARY_BLOB_HEAD referring to? This is quite large. A Google search throughs up nothing.
[code
GC: 20msec 1786140 bytes used, 5553528 bytes available
Type 0F (STRING ): 5928 bytes
Type 11 (CLASS ): 31212 bytes
Type 12 (VALUETYPE ): 7608 bytes
Type 13 (SZARRAY ): 19848 bytes
Type 01 (BOOLEAN ): 60 bytes
Type 02 (I1 ): 24 bytes
Type 03 (U1 ): 9768 bytes
Type 04 (CHAR ): 864 bytes
Type 05 (I2 ): 168 bytes
Type 06 (U2 ): 24 bytes
Type 07 (I4 ): 1464 bytes
Type 08 (U4 ): 336 bytes
Type 09 (R4 ): 24 bytes
Type 0F (STRING ): 2400 bytes
Type 11 (CLASS ): 4128 bytes
Type 12 (VALUETYPE ): 588 bytes
Type 15 (FREEBLOCK ): 5553528 bytes
Type 17 (ASSEMBLY ): 44736 bytes
Type 18 (WEAKCLASS ): 144 bytes
Type 19 (REFLECTION ): 216 bytes
Type 1B (DELEGATE_HEAD ): 1584 bytes
Type 1C (DELEGATELIST_HEAD ): 288 bytes
Type 1D (OBJECT_TO_EVENT ): 528 bytes
Type 1E (BINARY_BLOB_HEAD ): 1658220 bytes
Type 1F (THREAD ): 4224 bytes
Type 20 (SUBTHREAD ): 480 bytes
Type 21 (STACK_FRAME ): 4056 bytes
Type 22 (TIMER_HEAD ): 72 bytes
Type 26 (WAIT_FOR_OBJECT_HEAD): 96 bytes
Type 27 (FINALIZER_HEAD ): 984 bytes
Type 31 (IO_PORT ): 468 bytes
Type 34 (APPDOMAIN_HEAD ): 72 bytes
Type 36 (APPDOMAIN_ASSEMBLY ): 5376 bytes
]
The GC output close to when the application starts is pretty much the same values, give or take a few bytes.
I am going to go through the code with a fine tool comb to find this :)
That is the most fun part. 
Hi Dave,
Have you find a solution. I got the exact same problem on my EMX custom boards. Printing buffer ovflw on TE35 lcd after running 30 minutes. But all the serial ports , threads…etc are still running.
the version is 4.2.10
I guess its a serial port data reading issue.
Thanks.
Not yet but I tracked it down to the MFToolkit’s XBEE handler. It somehow gets out of sync with the bytes and the buffer overflows.
I made a few changes to the handler to detect this and it seems to be stable.
From this I would guess your serial ports buffer is overflowing. It’s not the same as the SERIAL OVERFLOW error which means that the serial byte received has not been read before the next one arrives. This error is the buffer itself overfilling.
What are you using the serial ports for?
Its a thuraya satallite modem. Sending and recieving AT commands only.
Can you add code to show the bytes still in the buffer? Just print it out to the debug either after you read the bytes from the buffer or elsewhere in the code. See if it is keeping up with the commands you are sending.
static void THURAYA_UART_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
byte[] buffer = new byte[THURAYA_UART.BytesToRead];
THURAYA_UART.Read(buffer, 0, buffer.Length);
string output_imu = bytesToString(buffer);
Debug.Print(output_imu );
output_imu = null;
buffer = null;
}
Even after I get the “buffer Ovflw” error on the LCD , I can send AT commands to the port , and keep seing the incoming data from the debug output window.
Will it help to keep monitoring the size of the serial buffer and do a serial.DiscardInBuffer when it becomes too big to avoid the overlow error. (Guess it is also not ideal as you might lose valuable data doing that, but if it only happens after long periods of time, it might be better than the buffer overlow error)
Thanks, but discardinbuffer didnt help.
I am trying to narrow down the issue …