Buffer OVFLW on EMX

NETMF & Gadgeteer
21

Interesting:
This code does not empty the buffer…


using System;
using System.IO.Ports;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHI.Premium.Hardware;
using System.Threading;

namespace TESTBufferCom
{
    public class Program
    {
        public static void Main()
        {
            Debug.Print(Resources.GetString(Resources.StringResources.String1));
            SerialPort UART = new SerialPort("COM2",38400);
            int counter = 0;
            UART.DataReceived += new SerialDataReceivedEventHandler(ThrowDataReceivedHandler);
            UART.Open();


            while(true)
            {
                Thread.Sleep(1000);
                Debug.Print(DateTime.Now.ToLocalTime().ToString() + " " + UART.BytesToRead.ToString());
            }
        }
        /// <summary>
        /// This method throw each data received on the com port. This avoid to get buffer overflow
        /// </summary>
        /// <param name="sender"></param>
        /// <param name="e"></param>
        public static void ThrowDataReceivedHandler(object sender,SerialDataReceivedEventArgs e)
        {
            SerialPort sp = (SerialPort)sender;
            sp.DiscardInBuffer();
        }
    }
}

but if you replace the discard statement by:

byte[] buf = new byte[sp.BytesToRead];
            sp.Read(buf,0,buf.Length);

The behaviour is ok.

There’s a bug somewhere!!!

22

Hi,
in an application I used the handler like this. Do not know if it is really different to your code

 
void ThrowDataReceivedHandler(SerialPort sender,SerialDataReceivedEventArgs e)
        {
            sender.DiscardInBuffer();
        }
23

We see this issue and working on it,
Thank for your feedback

24

@ RoSchmi - This shouldn’t make any difference but let’s try.

@ Dat - Ok I hope you will succeed to solve that.

25

@ leforban -

It looks like something was changed in UART NETMF4.2

Yes, it should not stop the app, but after you stopped your sending, the application will be continue.
In DataReceiveHandler, you should read your buffer to avoid buffer overflow like you posted.

26

@ Dat - Using read in the DataREceivedHandler is just not the solution it’s a trick to empty the buffer. Sometimes when the runtime is critical why wasting runtime to read data that are unusefull… (other than solving this bug). And even there’s still something buggy since discarding the buffer (using the appropriate method: DiscardInBuffer as mentionned by the MSDN) will not free the input buffer.

Is it something that we have to report on Codeplex?

27

Any news about this?

28

@ leforban -

We spent few hours on that and see that it is not easy to fix, and this is not our top priority now. We will go back with this later.

29

Ok Dat. Is this something that affect only EMX? GHI products? what about other netmf devices? If it affect all netmf devices an issue has to be defined on codeplex. If it affect only GHI devices, it’s on your own… I can not force you to solve it now but the trick that consists in dropping incoming data is not the ideal solution…

30

@ Dat - did you find an issue? When I looked at it i didn’t see an issue!

31

Interesting ! Gus did you try the sample code i provide on emx and 4.2 sdk ? If so therés something weird…

32

What I noticed was the events are not raised while data are being sent with continuous buffer overflow. As soon as data stopped, events were fired. But the com still work after.

33

So according to me there’s something that do not work properly.:
[ul]
Buffer OVFL shouldn’t pause the application.
DiscardInBuffer seems to have no effect
[/ul]

Gus: I notice the same thing than you, if data stop, application run then fine.

34

@ Mike -

Ghent.

Been there many times… Ever heard of Xeikon N.V?

Mostly work. Little play time…

Everyone there spoke at least 5 languages… I have been working on English for many years and still do not have it down pat…

35

@ leforban - I agree firing events too quickly should not lock up the system. My guess is that Microsoft changed something on 4.2. while we cant change the core, we maybe can add a flag internally to raise overflow error just one time.

36

We fixed it.

37

@ Dat - Ok thanks for your feedback and interest in this issue. What’s next? is there a patch? a new version of Premium or SDK?

38

Next SDK is few weeks away. We will let you know if we have more info.

39

Hi ,
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
Any solution yet?

Thanks.

40

@ denizalp -

Update the newest one 4.2.11.0, it should be gone!