COM port works in debug mode, not in free run mode...

  • Thread starter Thread starter jodleren
  • Start date Start date
J

jodleren

Hi

My code is below. My problem is that I am trying to receive data from
some hardware, and it works when I am debugging it. But when I run it
in released mode, I get junk data - my strings get mixed up.
And now when writing this, I just checked something - and found, that
a break point in runtime, and I see that my received data is ok, but
my readout (the 2 subsrings) causes the problems. Like they cannot
handle the amount of data. Any ideas?

My problem:
line = ReceivedLine.Substring(0, i).Trim();
string tmp = ReceivedLine.Substring(i + 1);
ReceivedLine = tmp;


Entire code:

Conn.NewLine = '\r'.ToString(); //set packet terminator
Conn.DataBits = 8;
Conn.BaudRate = 115200;
Conn.Parity = System.IO.Ports.Parity.None;
Conn.StopBits = System.IO.Ports.StopBits.One;
Conn.DataBits = 8;
Conn.DtrEnable = true;
Conn.RtsEnable = true;
Conn.ReadTimeout = Conn.WriteTimeout = 500;//ms
Conn.DataReceived += Conn_DataReceived;


// handle data received
string ReceivedLine;
private void Conn_DataReceived(object sender,
System.IO.Ports.SerialDataReceivedEventArgs e)
{
string line;

ReceivedLine = Conn.ReadExisting();// reader.ReadLine();

while((i = ReceivedLine.IndexOf('\r')) != -1)
{
line = ReceivedLine.Substring(0, i).Trim();
string tmp = ReceivedLine.Substring(i + 1);
ReceivedLine = tmp;

__Log2(line);
if (line != "")
{
if (line.Substring(0, 1) == "!")
__Log2("dataline");
}
}
 
Hi

My code is below. My problem is that I am trying to receive data from
some hardware, and it works when I am debugging it. But when I run it
in released mode, I get junk data - my strings get mixed up.
And now when writing this, I just checked something - and found, that
a break point in runtime, and I see that my received data is ok, but
my readout (the 2 subsrings) causes the problems. Like they cannot
handle the amount of data. Any ideas?

My problem:
                line = ReceivedLine.Substring(0, i).Trim();
                string tmp = ReceivedLine.Substring(i +1);
                ReceivedLine = tmp;

Entire code:

            Conn.NewLine = '\r'.ToString(); //set packet terminator
            Conn.DataBits = 8;
            Conn.BaudRate = 115200;
            Conn.Parity = System.IO.Ports.Parity.None;
            Conn.StopBits = System.IO.Ports.StopBits.One;
            Conn.DataBits = 8;
            Conn.DtrEnable = true;
            Conn.RtsEnable = true;
            Conn.ReadTimeout = Conn.WriteTimeout = 500;//ms
            Conn.DataReceived += Conn_DataReceived;

        // handle data received
        string ReceivedLine;
        private void Conn_DataReceived(object sender,
System.IO.Ports.SerialDataReceivedEventArgs e)
        {
            string line;

            ReceivedLine = Conn.ReadExisting();// reader.ReadLine();

            while((i = ReceivedLine.IndexOf('\r')) != -1)
            {
                line = ReceivedLine.Substring(0, i).Trim();
                string tmp = ReceivedLine.Substring(i +1);
                ReceivedLine = tmp;

                __Log2(line);
                if (line != "")
                {
                    if (line.Substring(0, 1) == "!")
                        __Log2("dataline");
                }
            }
Click to expand...

This is a shot in the dark. The fact that the debug and release
versions do different things suggests a possible timing problem.
I.e., a breakpoint might give an operation time to complete that
wouldn't normally have time to complete. Microsoft sometimes tries to
improve the performance of certain operations by letting them run
asynchronously and naively assume that they will be done before you
try to access the returned value. I know that it doesn't seem logical
for the code not to wait until the entire value is returned, but that
is exactly what happens with some DAO operations in Access databases.
Perhaps getting data from a COM port is enough like getting data from
a database for the same philosophy to be in play. To test out that
hypothesis, put in a delay after the line:

ReceivedLine = Conn.ReadExisting();// reader.ReadLine();

to ensure that the entire value has been read before trying to create
your substrings. If an adequate delay doesn't fix the substrings,
then the problem lies elsewhere. If you determine that your code is
actually timing sensitive, then you can't even be sure that the
correct value you get during debugging means that the code for that
result is correct! Curiosity might have killed the cat, but
Schrödinger might have brought it back :-). You just need to use some
logic to come up with tests that rule out potential timing issues.

James A. Fortune
(e-mail address removed)
 
This was it:


should be '


seems like working late at night is not the best....
Click to expand...

jodleren,

I'm glad you found the problem. But please explain how that change
fixed the problem. It doesn't seem possible to me that such a change
would account for it working correctly in debug mode but not in
release. Shouldn't the bug have affected both builds?

James A. Fortune
(e-mail address removed)
 
If the issue is timing as you offered, the change can still make a
difference. Because, in debug mode, the receive event may have enough time
to read in all the data.

This was it:


should be '


seems like working late at night is not the best....
Click to expand...

jodleren,

I'm glad you found the problem. But please explain how that change
fixed the problem. It doesn't seem possible to me that such a change
would account for it working correctly in debug mode but not in
release. Shouldn't the bug have affected both builds?

James A. Fortune
(e-mail address removed)
 
Sorry, hit enter too soon.

If the issue is timing as you offered, the change can still make a
difference. Because, in debug mode, the receive event may have enough time
to read in all the data, and never need to concatenate.
 
Sorry, hit enter too soon.

If the issue is timing as you offered, the change can still make a
difference. Because, in debug mode, the receive event may have enough time
to read in all the data, and never need to concatenate.
Click to expand...

Thanks for the explanation. Did you try using "volatile" as Peter
suggested? If so, was there a difference?

James A. Fortune
(e-mail address removed)
 
Back
Top