Skip to main content

You are here

Corrupted characters with Serial.print

9 posts / 0 new
Last post
Corrupted characters with Serial.print

I was having problems where the last text message before calling rf12_sleep(RF12_WAKEUP) was being corrupted. Serial.flush() did not improve the situation. A 20 second delay would allow the buffer to clear but that isn't so good. I searched on Google and found this: comment #3

The above has improved the situation but there is still corruption on long strings - but not the last string.


@JohnO This is exactly what I was fighting last week and was able to fix on JN6 with Serial.flush(). But I needed to put it after almost every Serial.println(), which adding fractions of milliseconds every time :(

Could you include your complete setup so we could compare?

Mine is: JN6, Ardude 1.0.2 for MacOSX, JeeLib RF12mods as of 19Nov2012.


I'm JN-USB & JN5, Arduino 1.0.1 on Win7x64 with @tht's RF12mods. I have tested without the @tht modification and it doesn't help. My Arduino was cobbled quite heavily to get Tiny84 working so I am not sure how comparable things are.

My serial.println() is working reasonably now although I'm sure it isn't 100%.


May be I was not completely clear - at one point I had ALL output characters wrong (like when the Serial speed is wrong), not just missing some.


The reason for Serial.flush() is that Serial I/O is based on interrupts. Sending something out no longer causes the sketch to stop until that is done. When the processor is put to sleep, it cannot handle the serial I/O (the serial clock is stopped). So you have to wait for all serial I/O to get finished before entering sleep mode. I suspect that the Serial.flush() code only waits until the last character has been set to the UART, not until it has actually been sent out. So my hunch is that Serial.flush() is in fact not waiting long enough.

Haven't researched it further yet. A loop to wait until the hardware bit in the UART says that the TX buffer is empty would probably be a more robust mechanism.

Another potential source of problems in case of the ATtiny is that it runs off its internal RC oscillator, which is only 10% accurate I think. That's marginal for UART use, i.e. to get 1 start + 8 data + 1 stop bit out with accurate timing. Calibrating the internal oscillator would also be a good idea. Yet more I haven't explored sufficiently yet...

You could try heating or cooling your ATtiny a bit, to see if it affects the error rate.


I'm curious, is it just inconvenience [as Serial usually used for debugging messages] or you have an actual logic affected? Which one then?


Just debugging, I don't use serial much beyond that.


The sleep problem is exactly what you're thinking, jcw. Serial.flush() only waits until the userland ring buffer has 0 characters in it. At that time there are up to 2 bytes still to send: 1 in the shift-out buffer, and one in the transmit buffer.

This has actually been fixed in the Arduino mainline git about 6 or 8 months ago, where Serial.flush() waits until even the bytes in the AVR buffers are sent, by checking a register flag (which I can't remember off the top of my head).


Hmm, interesting... I ran into something similar on one of my projects, but worked around it (serial output was only for debugging).

Premium Drupal Themes by Adaptivethemes