Gosu Cherry

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

7 years, 3 months ago.

[Serial] Serial does not always recieve endline character

Hi! I have this very weird situation. I own two nucleos F401RE, but one in like half year older than the second one (and one have X2 oscillator, second doesnt). Well, Im facing weird problem right now - to present the problem, I've created simple program (loaded on both devices).

Simple Program

#include "mbed.h"
#include <string> 

Serial pcSerial(SERIAL_TX,SERIAL_RX);
DigitalOut myLed(LED1);

int main() {
    pcSerial.baud(230400);
    pcSerial.printf("Master Ready!\n");
    myLed =1;
    while(1){
    }
}

As you can se, the program just prints the message, then switches LED on. Older device, without X2, loads alittle bit slower (0,25 sec lower) than the newer one, but works just fine. The newer one boots much faster (it's not connected with printing, it just loads faster, even if nothing is printed) BUT it almost always forgets to print "\n" character! This results in getting no message at all (im using TeraTerm). If I repeatedly reset device, it will eventually work, but flooding whole Terminal with previous "Master Ready!" messages. Any idea what is happening here?

Can you change the length of the messages and see if it's the \n or the 14th character that is causing the problem. It could be that you have a very slight baud rate difference between the two ends of the link, over a few bytes the error isn't enough to stop things working but on longer bursts of data without any pauses between bytes the two ends get more and more out of sync until data gets lost. This will be down to clock tolerances and so a slight unit to unit variation is to be expected, especially if they have different clock sources. Another thing to try would be checking whether dropping the baud rate fixes the problem or just moves it, e.g. if you have half the rate does it drop the 28th character rather than the 14th?

posted by Andy A 18 Sep 2017

Thank you for a good clues! After adding one character to the string, the newline character is not corrupted anymore, and the whole message prints just fine! It seems to be a problem with 14'th character and its multiples. When the message is 24 character long (and the 14'th character is \n) the problem also occurs (both on 115200 and 230400 bauds). Importantly, the data is not lost, because when eventually the messages arrives, every single character is correct. I thought it could be some buffering issue, but ending message with "\n" at printf, should empty the buffer.

posted by Gosu Cherry 18 Sep 2017
Be the first to answer this question.