How to debug timing issues with Code::Blocks

[Blacksheep]

Hi all,

I am trying to debug an obvious timing issue:

I have a microcontroller connected via usb2serial to my PC. The microcontroler is just sending 3-digits counting, surrounded by a start/stop char, upwards in a loop:

Code

    String msgstart;
    String msgend;
    String msg;
    msgstart  = '!';
    msgend    = '#';
    for (long i=100; i <= 999; i++){
      msg = msgstart + String(i) + msgend;
      Serial.println(msg);
    }

My application is reading the data and just dump them out via wxLogMessage. The code is basically this:

Code

// TODO (me#1#): Implement Timeout!

// something received?
            if( readed > 0 ) {
                receiveBuf[ readed ] = 0;  // Read data from serial port
                    wxString delstring;
                    wxStringTokenizer tokenizer(receiveBuf, "!#");  // Tokenize the buffer. Going from CHAR to wxString by this!
                    while ( tokenizer.HasMoreTokens() )
                    {
                        delstring = tokenizer.GetNextToken().Trim(true).Trim(false);
                        delstring.Replace("\r\n","");  // Remove any CRLF from string
                        if ( delstring.empty()){  // Do nothing if I am empty
                        } else {
                        q.push(delstring);  // Push me into FIFO queue
                        wxLogMessage(delstring); // Print me into the log
                        Sleep(100); // Just wait a little bit
                        }
                    }
            } // endif

	   } while( readed > 0 );

    } // while( true )

    device->Close();

    delete device;

Note that this code is running in an own thread.

This works, whenever not perfekt. I have sometimes peaks of crap or only 1 or 2 digits in the output like this (marked b/i) in my output:

09:27:32: Message: MyThread Entry()
09:27:32: Message: ctb::SerialPort* serialPort = new ctb::SerialPort();
09:27:32: Message: IF serialPort->Open
09:27:32: Message: Enter while read
09:27:32: 

984
09:27:32: 985
09:27:33: 986
09:27:33: 987
09:27:33: 988
09:27:33: 989
09:27:33: 990
09:27:33: 991
...
09:27:44: 188
09:27:44: 189
09:27:44: 190
09:27:44: 191
09:27:44: 1
09:27:44: 92
09:27:44: 193
09:27:45: 194
09:27:45: 195
09:27:45: 196
...
09:27:46: 208
09:27:46: 209
09:27:46: 21
09:27:46: 0
09:27:46: 211
09:27:47: 212
09:27:47: 213

My rubberduck told me that this might be a timing issue as this does not happen if I am in the debug mode. But I have no clue how I can track down timing issues. Does someone have a hint / document for me how to dive into this?

Thanks in advance!

Regards
Blacksheep

[BlueHazzard]

Hi,
in general this is not a codeblocks question per se and i think this topic will get locked, but anyway:

I don't see the code, that reads from the serial port, so i am speculating.... You don't know when your thread comes to the serial read function and what the buffer state at this point is.
So in the serial read function read always as long as you don't receive the end character. Don't start tokenizing before you have at least one complete message in the buffer, and stop after a complete message....
I think you read always as many characters you have on the buffer and then start tokenizing. But this is not the right way. As i said you do not have any guarantee about completeness of the message and you have to check this before you start the processing. Your error is because you have some incomplete message at the end/beginning of the receiving buffer.

[EDIT:] you can check this by either printing the receiver buffer or by putting a breakpoint before the tokenizing function and inspecting the buffer a view times...

Also: if you are using serial communication some kind of crc would not be a bad thing... Serial is weak...

[Blacksheep]

Thanks for the feedback, whenever it is missing my question. I asked not for help for my Problem (I prefer to analyze issues by myself before asking the community for help) but for a "Howto" investigating timing issues using the debugger in Codeblocks. Ok, I agree, we can fight if this is a debugger or a codeblocks workflow / documentation issue.  My personal opinion is here: The more howto's / documentation is available the more attractive a product is.

For the remaining world running into a similar issue: The problem was on the Arduino side: The loop was too fast for the selected baud rate so the send buffer was messed up before it could be send. With a higher baud rate the problem disappeared and I am currently working on CRC32 check and asynchronous communication.

Regards
Blacksheep