UART sometimes missing first few characters on ATmega328P
$begingroup$
I wrote some code for the ATmega328P, (Packaged in a module that clones the Arduino Nano).
Normally when I send UART data from my computer to these micros, it is received just fine. However I have started a new project and I am getting intermittent characters missing from the beginning of a message.
The code I wrote thus far reads the incoming data and prints it back to the computer. I am trying to send "<A2>
". Something like 80% of the messages are received and printed back fine. The rest are missing characters. Oddly, they are at the beginning of the message, giving me "A2>
" or "2>
"
I am using a baud of 115200, though 9600 and even 600 appear to give the same ratio of bad messages. I tried swapping the micro and there was no change. I'm only sending messages once every 5 seconds or so.
The micro is being powered from the same USB cable going to the laptop that the data is sent over.
Below are oscilloscope/logic analyzer captures of two signals, one that worked fine and another that was missing characters. The probe is placed right at the "RX" pin and grounded right at "GND".
Update: As user duskwuff mentioned, the signals are actually not approaching 0V. The top of the logic decoder is located at around 1.5V. What can cause this if the ground of the board is grounded to the laptop?
Signal received as "<A2>
" (correct):
Signal received as only "2>
" (incorrect):
Those two signals look awfully close.
The purpose of my this code is to create a sort of protocol for received messages that processes them one at a time, even if multiples are sent all at once ("<A1><A2><A3>
...") or if they are sent in only partial pieces ("<A
" and then "2>
").
Here's the code:
const int pinBuzzer = A5; // the number of pin for the buzzer
unsigned long T = 0; // "T" value
//max input size expected for a single incoming msg
#define INPUT_SIZE 32
char serialCommandstr[INPUT_SIZE + 1];
char serialCommand_singleChar; //single char for itterating through incoming WX
byte serialCommandindex = 0; //index of RX buffer for itterating
bool serialCommand_msgPending = false; // if msg exists in buffer without termination ('>');
bool serialCommand_ready = false; // if terminated msg ready (a '>' is received)
void setup()
{
delay(500);
Serial.begin(115200);
} // END Setup()
void loop()
{
Serial.println("Waiting for input in the form of "<XY>"");
Serial.println("X=[A/B], Y=[1~8]");
serialCommand_ready = false;
while (serialCommand_ready == false)
{
serialPreParse();
}
if (serialCommandstr[1] == 'A')
{
T = (serialCommandstr[2] - 1) - char('0');
Serial.print("A, ");
}
Serial.print("T=");
Serial.print(T);
Serial.print("us...");
//Beep to indicate waveform start
tone(pinBuzzer, 1319, 50);
delay(51);
}
void serialPreParse()
{
if (Serial.available() && serialCommand_msgPending == false)
{
// NEW incoming message (buffer previously empty)
//reinitialize
serialCommandstr[0] = '';
serialCommand_singleChar = '';
serialCommandindex = 0;
serialCommand_msgPending = true; // if msg received without termination
serialCommand_ready = false; // if terminated msg ready
}
while (Serial.available())
{
if (serialCommandindex == INPUT_SIZE)
{
//maximum size of C string reached
break;
}
serialCommand_singleChar = Serial.read();
//strcat(serialCommand_singleChar, serialCommandstr);
serialCommandstr[serialCommandindex] = serialCommand_singleChar;
serialCommandindex++;
serialCommandstr[serialCommandindex] = ''; //null-termination
if (serialCommand_singleChar == '>')
{
//End of single msg.
serialCommand_ready = true;
serialCommand_msgPending = false;
break;
}
}
if (serialCommand_ready == true)
{
if (serialCommandstr[0] != '<')
{
Serial.println("nIncomplete command!");
}
Serial.println();
Serial.print("RX:"");
Serial.write(serialCommandstr);
Serial.println(""");
}
}
microcontroller atmega serial uart c++
$endgroup$
add a comment |
$begingroup$
I wrote some code for the ATmega328P, (Packaged in a module that clones the Arduino Nano).
Normally when I send UART data from my computer to these micros, it is received just fine. However I have started a new project and I am getting intermittent characters missing from the beginning of a message.
The code I wrote thus far reads the incoming data and prints it back to the computer. I am trying to send "<A2>
". Something like 80% of the messages are received and printed back fine. The rest are missing characters. Oddly, they are at the beginning of the message, giving me "A2>
" or "2>
"
I am using a baud of 115200, though 9600 and even 600 appear to give the same ratio of bad messages. I tried swapping the micro and there was no change. I'm only sending messages once every 5 seconds or so.
The micro is being powered from the same USB cable going to the laptop that the data is sent over.
Below are oscilloscope/logic analyzer captures of two signals, one that worked fine and another that was missing characters. The probe is placed right at the "RX" pin and grounded right at "GND".
Update: As user duskwuff mentioned, the signals are actually not approaching 0V. The top of the logic decoder is located at around 1.5V. What can cause this if the ground of the board is grounded to the laptop?
Signal received as "<A2>
" (correct):
Signal received as only "2>
" (incorrect):
Those two signals look awfully close.
The purpose of my this code is to create a sort of protocol for received messages that processes them one at a time, even if multiples are sent all at once ("<A1><A2><A3>
...") or if they are sent in only partial pieces ("<A
" and then "2>
").
Here's the code:
const int pinBuzzer = A5; // the number of pin for the buzzer
unsigned long T = 0; // "T" value
//max input size expected for a single incoming msg
#define INPUT_SIZE 32
char serialCommandstr[INPUT_SIZE + 1];
char serialCommand_singleChar; //single char for itterating through incoming WX
byte serialCommandindex = 0; //index of RX buffer for itterating
bool serialCommand_msgPending = false; // if msg exists in buffer without termination ('>');
bool serialCommand_ready = false; // if terminated msg ready (a '>' is received)
void setup()
{
delay(500);
Serial.begin(115200);
} // END Setup()
void loop()
{
Serial.println("Waiting for input in the form of "<XY>"");
Serial.println("X=[A/B], Y=[1~8]");
serialCommand_ready = false;
while (serialCommand_ready == false)
{
serialPreParse();
}
if (serialCommandstr[1] == 'A')
{
T = (serialCommandstr[2] - 1) - char('0');
Serial.print("A, ");
}
Serial.print("T=");
Serial.print(T);
Serial.print("us...");
//Beep to indicate waveform start
tone(pinBuzzer, 1319, 50);
delay(51);
}
void serialPreParse()
{
if (Serial.available() && serialCommand_msgPending == false)
{
// NEW incoming message (buffer previously empty)
//reinitialize
serialCommandstr[0] = '';
serialCommand_singleChar = '';
serialCommandindex = 0;
serialCommand_msgPending = true; // if msg received without termination
serialCommand_ready = false; // if terminated msg ready
}
while (Serial.available())
{
if (serialCommandindex == INPUT_SIZE)
{
//maximum size of C string reached
break;
}
serialCommand_singleChar = Serial.read();
//strcat(serialCommand_singleChar, serialCommandstr);
serialCommandstr[serialCommandindex] = serialCommand_singleChar;
serialCommandindex++;
serialCommandstr[serialCommandindex] = ''; //null-termination
if (serialCommand_singleChar == '>')
{
//End of single msg.
serialCommand_ready = true;
serialCommand_msgPending = false;
break;
}
}
if (serialCommand_ready == true)
{
if (serialCommandstr[0] != '<')
{
Serial.println("nIncomplete command!");
}
Serial.println();
Serial.print("RX:"");
Serial.write(serialCommandstr);
Serial.println(""");
}
}
microcontroller atmega serial uart c++
$endgroup$
1
$begingroup$
What is your 328Ps clock source, and at what frequency?
$endgroup$
– marcelm
7 hours ago
$begingroup$
It's a 16MHz crystal.
$endgroup$
– Bort
4 hours ago
$begingroup$
It sounds to me like the UART isn't synching up correctly. I'm not familiar with modern ones, but 40 years ago you could sometimes select the clock divider value -- 16 was normal but you could go to 4 if you knew your clock and the signal were in sync. The higher the divider (with the clock multiplied appropriately) the better, within reason.
$endgroup$
– Hot Licks
59 mins ago
$begingroup$
Another kinda stupid question is whether your program is enabling interrupts, polling, or whatever is needed at the appropriate time. If your program is off doing something else, or if it simply doesn't know the data has arrived, it will miss the data. (Do you check the UART's "overrun" flag?)
$endgroup$
– Hot Licks
55 mins ago
add a comment |
$begingroup$
I wrote some code for the ATmega328P, (Packaged in a module that clones the Arduino Nano).
Normally when I send UART data from my computer to these micros, it is received just fine. However I have started a new project and I am getting intermittent characters missing from the beginning of a message.
The code I wrote thus far reads the incoming data and prints it back to the computer. I am trying to send "<A2>
". Something like 80% of the messages are received and printed back fine. The rest are missing characters. Oddly, they are at the beginning of the message, giving me "A2>
" or "2>
"
I am using a baud of 115200, though 9600 and even 600 appear to give the same ratio of bad messages. I tried swapping the micro and there was no change. I'm only sending messages once every 5 seconds or so.
The micro is being powered from the same USB cable going to the laptop that the data is sent over.
Below are oscilloscope/logic analyzer captures of two signals, one that worked fine and another that was missing characters. The probe is placed right at the "RX" pin and grounded right at "GND".
Update: As user duskwuff mentioned, the signals are actually not approaching 0V. The top of the logic decoder is located at around 1.5V. What can cause this if the ground of the board is grounded to the laptop?
Signal received as "<A2>
" (correct):
Signal received as only "2>
" (incorrect):
Those two signals look awfully close.
The purpose of my this code is to create a sort of protocol for received messages that processes them one at a time, even if multiples are sent all at once ("<A1><A2><A3>
...") or if they are sent in only partial pieces ("<A
" and then "2>
").
Here's the code:
const int pinBuzzer = A5; // the number of pin for the buzzer
unsigned long T = 0; // "T" value
//max input size expected for a single incoming msg
#define INPUT_SIZE 32
char serialCommandstr[INPUT_SIZE + 1];
char serialCommand_singleChar; //single char for itterating through incoming WX
byte serialCommandindex = 0; //index of RX buffer for itterating
bool serialCommand_msgPending = false; // if msg exists in buffer without termination ('>');
bool serialCommand_ready = false; // if terminated msg ready (a '>' is received)
void setup()
{
delay(500);
Serial.begin(115200);
} // END Setup()
void loop()
{
Serial.println("Waiting for input in the form of "<XY>"");
Serial.println("X=[A/B], Y=[1~8]");
serialCommand_ready = false;
while (serialCommand_ready == false)
{
serialPreParse();
}
if (serialCommandstr[1] == 'A')
{
T = (serialCommandstr[2] - 1) - char('0');
Serial.print("A, ");
}
Serial.print("T=");
Serial.print(T);
Serial.print("us...");
//Beep to indicate waveform start
tone(pinBuzzer, 1319, 50);
delay(51);
}
void serialPreParse()
{
if (Serial.available() && serialCommand_msgPending == false)
{
// NEW incoming message (buffer previously empty)
//reinitialize
serialCommandstr[0] = '';
serialCommand_singleChar = '';
serialCommandindex = 0;
serialCommand_msgPending = true; // if msg received without termination
serialCommand_ready = false; // if terminated msg ready
}
while (Serial.available())
{
if (serialCommandindex == INPUT_SIZE)
{
//maximum size of C string reached
break;
}
serialCommand_singleChar = Serial.read();
//strcat(serialCommand_singleChar, serialCommandstr);
serialCommandstr[serialCommandindex] = serialCommand_singleChar;
serialCommandindex++;
serialCommandstr[serialCommandindex] = ''; //null-termination
if (serialCommand_singleChar == '>')
{
//End of single msg.
serialCommand_ready = true;
serialCommand_msgPending = false;
break;
}
}
if (serialCommand_ready == true)
{
if (serialCommandstr[0] != '<')
{
Serial.println("nIncomplete command!");
}
Serial.println();
Serial.print("RX:"");
Serial.write(serialCommandstr);
Serial.println(""");
}
}
microcontroller atmega serial uart c++
$endgroup$
I wrote some code for the ATmega328P, (Packaged in a module that clones the Arduino Nano).
Normally when I send UART data from my computer to these micros, it is received just fine. However I have started a new project and I am getting intermittent characters missing from the beginning of a message.
The code I wrote thus far reads the incoming data and prints it back to the computer. I am trying to send "<A2>
". Something like 80% of the messages are received and printed back fine. The rest are missing characters. Oddly, they are at the beginning of the message, giving me "A2>
" or "2>
"
I am using a baud of 115200, though 9600 and even 600 appear to give the same ratio of bad messages. I tried swapping the micro and there was no change. I'm only sending messages once every 5 seconds or so.
The micro is being powered from the same USB cable going to the laptop that the data is sent over.
Below are oscilloscope/logic analyzer captures of two signals, one that worked fine and another that was missing characters. The probe is placed right at the "RX" pin and grounded right at "GND".
Update: As user duskwuff mentioned, the signals are actually not approaching 0V. The top of the logic decoder is located at around 1.5V. What can cause this if the ground of the board is grounded to the laptop?
Signal received as "<A2>
" (correct):
Signal received as only "2>
" (incorrect):
Those two signals look awfully close.
The purpose of my this code is to create a sort of protocol for received messages that processes them one at a time, even if multiples are sent all at once ("<A1><A2><A3>
...") or if they are sent in only partial pieces ("<A
" and then "2>
").
Here's the code:
const int pinBuzzer = A5; // the number of pin for the buzzer
unsigned long T = 0; // "T" value
//max input size expected for a single incoming msg
#define INPUT_SIZE 32
char serialCommandstr[INPUT_SIZE + 1];
char serialCommand_singleChar; //single char for itterating through incoming WX
byte serialCommandindex = 0; //index of RX buffer for itterating
bool serialCommand_msgPending = false; // if msg exists in buffer without termination ('>');
bool serialCommand_ready = false; // if terminated msg ready (a '>' is received)
void setup()
{
delay(500);
Serial.begin(115200);
} // END Setup()
void loop()
{
Serial.println("Waiting for input in the form of "<XY>"");
Serial.println("X=[A/B], Y=[1~8]");
serialCommand_ready = false;
while (serialCommand_ready == false)
{
serialPreParse();
}
if (serialCommandstr[1] == 'A')
{
T = (serialCommandstr[2] - 1) - char('0');
Serial.print("A, ");
}
Serial.print("T=");
Serial.print(T);
Serial.print("us...");
//Beep to indicate waveform start
tone(pinBuzzer, 1319, 50);
delay(51);
}
void serialPreParse()
{
if (Serial.available() && serialCommand_msgPending == false)
{
// NEW incoming message (buffer previously empty)
//reinitialize
serialCommandstr[0] = '';
serialCommand_singleChar = '';
serialCommandindex = 0;
serialCommand_msgPending = true; // if msg received without termination
serialCommand_ready = false; // if terminated msg ready
}
while (Serial.available())
{
if (serialCommandindex == INPUT_SIZE)
{
//maximum size of C string reached
break;
}
serialCommand_singleChar = Serial.read();
//strcat(serialCommand_singleChar, serialCommandstr);
serialCommandstr[serialCommandindex] = serialCommand_singleChar;
serialCommandindex++;
serialCommandstr[serialCommandindex] = ''; //null-termination
if (serialCommand_singleChar == '>')
{
//End of single msg.
serialCommand_ready = true;
serialCommand_msgPending = false;
break;
}
}
if (serialCommand_ready == true)
{
if (serialCommandstr[0] != '<')
{
Serial.println("nIncomplete command!");
}
Serial.println();
Serial.print("RX:"");
Serial.write(serialCommandstr);
Serial.println(""");
}
}
microcontroller atmega serial uart c++
microcontroller atmega serial uart c++
edited 4 hours ago
Bort
asked 8 hours ago
BortBort
3,30011639
3,30011639
1
$begingroup$
What is your 328Ps clock source, and at what frequency?
$endgroup$
– marcelm
7 hours ago
$begingroup$
It's a 16MHz crystal.
$endgroup$
– Bort
4 hours ago
$begingroup$
It sounds to me like the UART isn't synching up correctly. I'm not familiar with modern ones, but 40 years ago you could sometimes select the clock divider value -- 16 was normal but you could go to 4 if you knew your clock and the signal were in sync. The higher the divider (with the clock multiplied appropriately) the better, within reason.
$endgroup$
– Hot Licks
59 mins ago
$begingroup$
Another kinda stupid question is whether your program is enabling interrupts, polling, or whatever is needed at the appropriate time. If your program is off doing something else, or if it simply doesn't know the data has arrived, it will miss the data. (Do you check the UART's "overrun" flag?)
$endgroup$
– Hot Licks
55 mins ago
add a comment |
1
$begingroup$
What is your 328Ps clock source, and at what frequency?
$endgroup$
– marcelm
7 hours ago
$begingroup$
It's a 16MHz crystal.
$endgroup$
– Bort
4 hours ago
$begingroup$
It sounds to me like the UART isn't synching up correctly. I'm not familiar with modern ones, but 40 years ago you could sometimes select the clock divider value -- 16 was normal but you could go to 4 if you knew your clock and the signal were in sync. The higher the divider (with the clock multiplied appropriately) the better, within reason.
$endgroup$
– Hot Licks
59 mins ago
$begingroup$
Another kinda stupid question is whether your program is enabling interrupts, polling, or whatever is needed at the appropriate time. If your program is off doing something else, or if it simply doesn't know the data has arrived, it will miss the data. (Do you check the UART's "overrun" flag?)
$endgroup$
– Hot Licks
55 mins ago
1
1
$begingroup$
What is your 328Ps clock source, and at what frequency?
$endgroup$
– marcelm
7 hours ago
$begingroup$
What is your 328Ps clock source, and at what frequency?
$endgroup$
– marcelm
7 hours ago
$begingroup$
It's a 16MHz crystal.
$endgroup$
– Bort
4 hours ago
$begingroup$
It's a 16MHz crystal.
$endgroup$
– Bort
4 hours ago
$begingroup$
It sounds to me like the UART isn't synching up correctly. I'm not familiar with modern ones, but 40 years ago you could sometimes select the clock divider value -- 16 was normal but you could go to 4 if you knew your clock and the signal were in sync. The higher the divider (with the clock multiplied appropriately) the better, within reason.
$endgroup$
– Hot Licks
59 mins ago
$begingroup$
It sounds to me like the UART isn't synching up correctly. I'm not familiar with modern ones, but 40 years ago you could sometimes select the clock divider value -- 16 was normal but you could go to 4 if you knew your clock and the signal were in sync. The higher the divider (with the clock multiplied appropriately) the better, within reason.
$endgroup$
– Hot Licks
59 mins ago
$begingroup$
Another kinda stupid question is whether your program is enabling interrupts, polling, or whatever is needed at the appropriate time. If your program is off doing something else, or if it simply doesn't know the data has arrived, it will miss the data. (Do you check the UART's "overrun" flag?)
$endgroup$
– Hot Licks
55 mins ago
$begingroup$
Another kinda stupid question is whether your program is enabling interrupts, polling, or whatever is needed at the appropriate time. If your program is off doing something else, or if it simply doesn't know the data has arrived, it will miss the data. (Do you check the UART's "overrun" flag?)
$endgroup$
– Hot Licks
55 mins ago
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
What jumps out to me here is the mark (low signal) levels in your UART signal. Marks should be close to zero, but the oscilloscope output you've included looks like it's only dropping to ~1.6V, especially on the first few characters. This is well above VIL for your microcontroller (0.2×VCC = 1V), so the microcontroller will not reliably interpret it as a logical low.
What hardware are you using to generate UART output from the computer? Make sure it shares a ground with the computer. If this doesn't help, it may be faulty and need to be replaced.
$endgroup$
2
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
return StackExchange.using("schematics", function () {
StackExchange.schematics.init();
});
}, "cicuitlab");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "135"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f418565%2fuart-sometimes-missing-first-few-characters-on-atmega328p%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
What jumps out to me here is the mark (low signal) levels in your UART signal. Marks should be close to zero, but the oscilloscope output you've included looks like it's only dropping to ~1.6V, especially on the first few characters. This is well above VIL for your microcontroller (0.2×VCC = 1V), so the microcontroller will not reliably interpret it as a logical low.
What hardware are you using to generate UART output from the computer? Make sure it shares a ground with the computer. If this doesn't help, it may be faulty and need to be replaced.
$endgroup$
2
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
add a comment |
$begingroup$
What jumps out to me here is the mark (low signal) levels in your UART signal. Marks should be close to zero, but the oscilloscope output you've included looks like it's only dropping to ~1.6V, especially on the first few characters. This is well above VIL for your microcontroller (0.2×VCC = 1V), so the microcontroller will not reliably interpret it as a logical low.
What hardware are you using to generate UART output from the computer? Make sure it shares a ground with the computer. If this doesn't help, it may be faulty and need to be replaced.
$endgroup$
2
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
add a comment |
$begingroup$
What jumps out to me here is the mark (low signal) levels in your UART signal. Marks should be close to zero, but the oscilloscope output you've included looks like it's only dropping to ~1.6V, especially on the first few characters. This is well above VIL for your microcontroller (0.2×VCC = 1V), so the microcontroller will not reliably interpret it as a logical low.
What hardware are you using to generate UART output from the computer? Make sure it shares a ground with the computer. If this doesn't help, it may be faulty and need to be replaced.
$endgroup$
What jumps out to me here is the mark (low signal) levels in your UART signal. Marks should be close to zero, but the oscilloscope output you've included looks like it's only dropping to ~1.6V, especially on the first few characters. This is well above VIL for your microcontroller (0.2×VCC = 1V), so the microcontroller will not reliably interpret it as a logical low.
What hardware are you using to generate UART output from the computer? Make sure it shares a ground with the computer. If this doesn't help, it may be faulty and need to be replaced.
edited 5 hours ago
answered 7 hours ago
duskwuffduskwuff
16.8k32650
16.8k32650
2
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
add a comment |
2
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
2
2
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
I think you may be onto something. The mark levels appear to drop lower over the course of he 4-character message, making the last one more likely to be recognized than the 1st.
$endgroup$
– brhans
7 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
Wow, I erroneously assumed that the signal was reaching near-zero because the logic decoder was right below it! Great catch, but I'm not sure how this can happen. I mentioned that the board is powered through the same USB cable that carries the data because I imagined ground issues would thus be ruled out. I even tried a different USB cable to no avail. What should I do next to isolate the cause?
$endgroup$
– Bort
4 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
$begingroup$
You probably have something else shorted to or driving the receive data pin
$endgroup$
– Chris Stratton
3 hours ago
add a comment |
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f418565%2fuart-sometimes-missing-first-few-characters-on-atmega328p%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
$begingroup$
What is your 328Ps clock source, and at what frequency?
$endgroup$
– marcelm
7 hours ago
$begingroup$
It's a 16MHz crystal.
$endgroup$
– Bort
4 hours ago
$begingroup$
It sounds to me like the UART isn't synching up correctly. I'm not familiar with modern ones, but 40 years ago you could sometimes select the clock divider value -- 16 was normal but you could go to 4 if you knew your clock and the signal were in sync. The higher the divider (with the clock multiplied appropriately) the better, within reason.
$endgroup$
– Hot Licks
59 mins ago
$begingroup$
Another kinda stupid question is whether your program is enabling interrupts, polling, or whatever is needed at the appropriate time. If your program is off doing something else, or if it simply doesn't know the data has arrived, it will miss the data. (Do you check the UART's "overrun" flag?)
$endgroup$
– Hot Licks
55 mins ago