HardwareSerial flush problem

[xxxajk]

HardwareSerial::flush() sits, spins, and never exits.
Mega 1280, Arduino 1.0.5

hardware/arduino/cores/arduino/HardwareSerial.cpp, line 457
replace
while (transmitting && ! (*_ucsra & _BV(TXC0)));
with
while (transmitting && _tx_buffer->head != _tx_buffer->tail);

fixes the issue.

[matthijskooijman]

Under what conditions are you calling flush()? With interrupts enabled? Or are you using a very high baudrate perhaps?

[xxxajk]

115200 baud. Write 1 char then call flush(), and it locks.
On Jun 11, 2013 5:38 AM, "Matthijs Kooijman" notifications@github.com
wrote:

Under what conditions are you calling flush()? With interrupts enabled? Or
are you using a very high baudrate perhaps?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1463#issuecomment-19251412
.

[matthijskooijman]

I just did a quick try on my Arduino Uno, and the following sketch works
as expected (prints xs on the serial port).

void setup() {
  Serial.begin(115200);
}

void loop() {
  Serial.print("x");
  Serial.flush();
}

So it seems the problem is not as general as you describe it and thus
there is something else particular to your setup that is needed to cause
the problem.

Could you provide more details about your testcase, perhaps the
(reduced) failing sketch?

Does the above sketch work for you?

What hardware are you using?

[xxxajk]

Mega1280, yes the case is specific, and complicated. Add me on Google+ and
I can explain better, and provide all details. It will require additional
hardware as well. I also have ability of connecting an AVR dragon via jtag
if you need any other info.
On Jun 11, 2013 10:46 AM, "Matthijs Kooijman" notifications@github.com
wrote:

I just did a quick try on my Arduino Uno, and the following sketch works
as expected (prints xs on the serial port).

void setup() {
Serial.begin(115200);
}

void loop() {
Serial.print("x");
Serial.flush();
}

So it seems the problem is not as general as you describe it and thus
there is something else particular to your setup that is needed to cause
the problem.

Could you provide more details about your testcase, perhaps the
(reduced) failing sketch?

Does the above sketch work for you?

What hardware are you using?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1463#issuecomment-19266353
.

[matthijskooijman]

Hmm, I don't actually have a Mega to test with, so this might get complicated indeed :-)

In any case, I would prefer it if you would explain the problem here in this ticket, so others can also read it. I'm just trying to get the problem clear, I might not be the one to actually investigate or fix it.

You suggested a fix in your original report, but that fix is not correct: It reduces the flush() call from "all bytes sent" to "all bytes written to the UART", so with your changes if someone calls flush() and then shuts down the TX pin, he might have missed one or two bytes.

I recently created a pile of fixes for HardwareSerial that haven't been merged yet. Perhaps you could see if they fix your problem as well? They're at #1369.

Alternatively, there is a deadlock fix for high baudrates, perhaps you're seeing the same problem at lower baudrates for some reason? The proposed fix is at #1456, could you see if that changes anything for you?

Having said that, if you think explaining through some messaging platform works better, feel free to join #arduino on the Freenode IRC network. My nickname is blathijs there.

[xxxajk]

I'll try that and let you know.
On Jun 11, 2013 11:07 AM, "Matthijs Kooijman" notifications@github.com
wrote:

Hmm, I don't actually have a Mega to test with, so this might get
complicated indeed :-)

In any case, I would prefer it if you would explain the problem here in
this ticket, so others can also read it. I'm just trying to get the problem
clear, I might not be the one to actually investigate or fix it.

You suggested a fix in your original report, but that fix is not correct:
It reduces the flush() call from "all bytes sent" to "all bytes written to
the UART", so with your changes if someone calls flush() and then shuts
down the TX pin, he might have missed one or two bytes.

I recently created a pile of fixes for HardwareSerial that haven't been
merged yet. Perhaps you could see if they fix your problem as well? They're
at #1369 #1369.

Alternatively, there is a deadlock fix for high baudrates, perhaps you're
seeing the same problem at lower baudrates for some reason? The proposed
fix is at #1456 #1456, could
you see if that changes anything for you?

Having said that, if you think explaining through some messaging platform
works better, feel free to join #arduino on the Freenode IRC network. My
nickname is blathijs there.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1463#issuecomment-19267599
.

[xxxajk]

#1456 fixes it for me. My guess is that since I am not operating on internal RAM, but instead external RAM, that the extra clock cycles trip the deadlock easier. Consider this a verification that it can happen at lower baud rates under the right conditions, such as mine.

Oh and before I forget, The other factor involved here is that I am multitasking on the external RAM as well.

Here is the successful output.

Task A
Waiting for '/' to mount......Starting test...
File opened OK, displaying contents...
Hello world!

Read completed, last read result = -1 (20).
File closed, result = 0.
Remove and insert media...